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This  manual  is  issued  under  the  authority  of  Department  of  Defense  (DoD)  Directive  8320.1, 
"Department  of  Defense  Data  Administration,"  26  September  1991.  It  prescribes  procedures 
for  the  development,  approval,  and  maintenance  of  the  DoD  Enterprise  Data  Model  and 
management  necessary  to  support  the  policies  of  DoD  Data  Administration  as  established  by 
DoD  Directive  8320.1. 

This  manual  applies  to  the  Office  of  the  Secretary  of  Defense  (OSD),  the  Military 
Departments,  the  Chairman  of  the  Joint  Chiefs  of  Staff  and  Joint  Staff,  the  Unified 
Commands,  the  Inspector  General  of  the  Department  of  Defense  (IG  DoD),  the  Defense 
Agencies,  and  the  DoD  Field  Activities  (hereafter  referred  to  collectively  as  "the  DoD 
Components").  Its  provisions  are  applicable  to  all  new  initiatives  to  develop,  modernize,  or 
migrate  information  systems,  whether  automated  or  non-automated. 

This  manual  is  effective  immediately;  its  use  by  all  DoD  Components  is  mandatory. 

Send  recommended  changes  to  the  manual  to: 

Center  for  Software 

Chief,  Data  Administration  Department 

5600  Columbia  Pike 

Falls  Church,  VA  22041 

The  DoD  Components  may  obtain  copies  of  this  manual  through  their  own  publications 
channels.  Defense  contractors  and  other  Federal  Agencies  may  obtain  copies  from: 

Defense  Technical  Information  Center  (DTIC) 

Building  5,  Cameron  Station 
Alexandria,  VA  22034  -  6145 

Commercial  telephone:  1-800-225-DTIC  (1-800-225-3842) 

The  public  may  obtain  copies  from: 


U.S.  Department  of  Commerce 

National  Technical  Information  Service  (NTIS) 

5285  Port  Royal  Road 

Springfield,  VA  22161 

Commercial  telephone:  1-703-487-4650 
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DEFINITIONS 


1.  Activity  Models.  (See  Modeling) 

2.  Alternate  Key.  Attribute(s)  that  can  be  used  to  uniquely  identify  an  entity  instance, 
but  that  is  not  designated  as  part  of  the  entity  primary  key.  DoD  IDEF  Workshop 
Participants  Guide  (reference  (a)). 

3.  Approved  Standard  Data  Element.  A  standard  data  element  that  has  been  coordinated 
through  the  standardization  process  and  approved  for  use  in  DoD  systems  and  models.  DoD 
8320.1-M-l  (reference  (b)). 

4.  Associative  Entity.  An  entity  that  inherits  its  primary  key  from  two  or  more  other 
entities  and  documents  multiple  associations  (relationships)  between  those  entities.  The 
primary  use  of  associative  entities  is  to  reconcile  non-specific  (many-to-many)  relationships 
between  two  or  more  entities.  An  associative  entity  has  no  unique  key  attributes;  if  it  does, 
it  becomes  an  attributive  entity.  The  difference  between  an  associative  entity  and  an 
attributive  entity  is  the  number  of  identifying  relationships  to  the  parent.  An  attributive  entity 
has  only  one  identifying  relationship,  and  an  associative  entity  has  more  than  one.  An 
associative  entity  is  also  known  as  an  intersecting  entity. 

5.  Attribute.  A  property  or  characteristic  of  an  entity  or  entity  class.  For  example, 
COLOR,  WEIGHT,  GENDER.  All  attributes  describe  an  entity.  There  are  two  types  of 
attributes:  key  and  non-key. 

a.  Key  Attribute.  An  attribute  that  may  be  used  to  uniquely  identify  an  instance 
of  an  entity  or  entity  class.  There  are  three  types  of  key  attributes:  primary  keys,  alternate 
keys,  and  foreign  keys. 

b.  Nonkev  Attribute.  Attribute  or  group  of  attributes  that  describe  an  entity  but 
that  can  not  be  used  to  uniquely  identify  the  entity  or  relate  the  entity  to  another  entity. 

6.  Attributive  Entity.  An  entity  that  accommodates  repeating  attributes  for  the  parent 
entity.  Additional  attributes  are  appended  to  the  key  structure  of  the  attributive  entity  that  do 
not  appear  in  the  key  structure  for  the  parent  entity.  These  additional  key  attributes  uniquely 
distinguish  between  multiple  values  for  the  repeating  attributes.  An  attributive  entity  is  a 
dependent  entity  with  exactly  one  identifying  parent.  Attributive  entities  are  created  to 
support  the  first  rule  of  normalization:  eliminating  repeating  attributes  from  the  parent  entity. 
Also  known  as  a  characteristic  entity. 

7.  Business  Rule.  A  statement  or  fact  that  defines  the  constraints  governing  how  data  are 
processed  (e.g.,  referential  integrity  constraints  for  add,  change,  and  delete  transactions  against 
records  in  a  database).  Business  rule  statements  describe  these  constraints.  For  example, 
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referential  integrity  constraints  can  be  derived  from  relationships  defined  in  a  data  model.  For 
this  type  of  constraint,  each  business  rule  statement  should  be  constructed  so  that  the  parent 
entity  name  is  the  subject,  the  relationship  name  is  the  verb  phrase,  and  the  child  entity  name 
is  the  object. 

8.  Candidate  Identifier.  (See  Attribute  -  Key  Attribute  &  Candidate  Key) 

9  Candidate  Key.  Property  or  characteristic  of  an  entity  that  is  considered  to  be  a 

potential  primary  key.  Also  known  as  candidate  identifier. 

10.  Cardinality.  A  statement  of  the  number  of  entity  instances  that  may  or  must 
participate  at  each  end  of  a  relationship.  (See  Relationship).  Cardinality  is  the  combination 
of  degree  and  nature. 

a.  Degree.  An  expression  describing  the  number  of  instances  from  one  entity 
occurrence  that  may  be  associated  to  another  entity  occurrence.  Expressions  include  one  (1), 
many  (N  or  M),  or  predetermined  number  (e.g.,  2).  For  example,  Each  EQUIPMENT  ITEM 
supports  zero,  one,  or  many  WEAPON  SYSTEMS(s);  Each  WEAPON  SYSTEM  is  supported 
by  one  or  many  EQUIPMENT  ITEMS(s).  Entity  relationships  degrees  are  generally  described 
as  one-to-one,  one-to-many,  or  many-to-many.  Specific  numbers  (two  through  infinity)  are 
optional. 

b.  Nature.  Expresses  whether  the  association  from  one  entity  occurrence  to 
another  entity  occurrence  is  mandatory  (obligatory)  or  optional  (nonobligatory).  Expressions 
include  one  (1)  for  mandatory  and  zero  (0)  for  optional.  If,  for  example,  EQUIPMENT  ITEM 
supports  zero,  one  or  many  WEAPON  SYSTEMS(s),  then  WEAPON  SYSTEM  is  in 
optionally  related  to  EQUIPMENT  ITEM;  If  WEAPON  SYSTEM  is  supported  by  oneor 
many  Equipment  Item(s),  then  EQUIPMENT  ITEM  is  in  a  mandatory  relationship  to 
WEAPON  SYSTEM.  An  ambiguous  many-to-many  relationship  is  permitted  only  at  the 
entity-relationship  level  of  a  data  model.  Dependency  cannot  be  discerned  in  nonspecific 
relationships.  It  must  be  identified  at  the  key-based  level. 

1 1 .  Category  Discriminator.  An  attribute  that  determines  to  which  category  a  generic 
parent  instance  belongs. 

12.  Category  Entity.  A  subset  of  the  instances  of  a  single  parent  entity  (referred  to  as  a 
generalization  entity  or  generic  parent).  The  subset  inherits  common  attributes  and/or 
relationships  from  the  parent,  including  its  primary  keys  (which  become  foreign  keys  in  the 
category  entity).  The  category  entity  contains  additional  attributes  and/or  relationships  that 
are  related  to  the  parent  but  that  are  distinct  from  other  related  subsets.  It  also  contains  some 
attributes  and/or  relationship(s)  that  apply  only  to  instances  of  the  subset  and  not  to  all 
instances  of  the  parent.  Category  entities  are  used  to  help  migrate  a  data  model  to  fourth- 
normal  form,  because  they  eliminate  null  attribute  values  in  the  parent  entity.  Also  known  as 
subentity  or  secondary  entity. 
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13.  Characteristic  Entity.  (See  Attributive  Entity) 

14.  Child  Entity.  The  entity  to  which  a  relationship  contributes  a  foreign  key. 

15.  Class  Word.  A  word  in  the  name  of  a  data  element  (attribute)  describing  the  category 
to  which  the  data  element  belongs,  e.g.,  "quantity,"  name,"  "code."  The  word  establishes  the 
general  structure  and  domain  of  a  standard  data  element.  (NBS  Special  Pub  500-149) 

16.  Composite  Attributes.  Composite  attributes  describe  multiple  concepts.  When  an 
attribute  is  formulated  to  describe  multiple  concepts,  its  definition  and  meaning  can  easily 
partially  overlap  with  the  definition  of  another  attribute.  This  redundancy  sets  the  stage  for 
data  inconsistencies,  increases  system  maintenance  costs,  and  restricts  the  use  of  a  data 
element  to  a  narrow  range  of  applications. 

17.  Conceptual  Schema.  (See  Schema  -  Conceptual  Schema) 

18.  Data.  A  representation  of  facts,  concepts,  or  instructions  in  a  formalized  manner 
suitable  for  communication,  interpretation,  or  processing  by  humans  or  by  automatic  means. 
(FIPS  Pub  11-3) 

19.  Data  Administration.  That  function  of  the  organization  that  oversees  the  management 
of  data  across  the  enterprise  and  is  responsible  for  central  information  planning  and  control. 

20.  Data  Administrator  tDAd).  A  person  or  group  that  ensures  the  utility  of  data  used 
within  an  organization.  Responsibilities  include  defining  data  policies  and  standards,  planning 
for  the  efficient  use  of  data,  coordinating  data  structures  among  organizational  components, 
performing  logical  database  designs,  and  defining  data  security  procedures. 

21.  Data  Architecture.  The  framework  for  organizing  and  defining  the  interrelationships  of 
data  in  support  of  an  organization's  missions,  functions,  goals,  objectives,  and  strategies.  Data 
architectures  provide  the  basis  for  the  incremental,  ordered  design  and  development  of 
systems  based  on  successively  more  detailed  levels  of  data  modeling.  (DoD  8320. 1-M) 

22.  Data  Definition  Language  (DDL).  The  language  used  to  define  physical  data 
structures  in  a  database  management  system. 

23.  Data  Dependence.  The  property  of  data  where  the  existence  of  the  data  depends  on 
the  existence  of  other  pieces  of  data. 

24.  Data  Dictionary.  A  specialized  type  of  database  containing  metadata  that  are  managed 
by  a  data  dictionary  system;  a  repository  of  information  describing  the  characteristics  of  data 
used  to  design,  monitor,  document,  protect,  and  control  data  in  information  systems  and 
databases;  an  application  of  a  data  dictionary  system.  (NBS  Spec  Pub  500-152) 
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25.  Data  Element.  A  named  identifier  of  each  of  the  entities  and  their  attributes  that  are 
represented  in  a  database  (DoD  8320. 1-M). 

26  Data  Element  Standardization.  The  process  of  documenting,  reviewing,  and  approving 
unique  names,  definitions,  characteristics,  and  representations  of  data  elements  according  to 
established  procedures  and  conventions.  (DoD  8320.1-M-l) 

27.  Data  Entity.  See  Entity 

28.  Data  Independence.  A  property  of  data  where  the  structure  and  format  of  the  data  are 
independent  of  the  applications  that  access  the  data. 

29  Data  Integrity.  A  property  of  data  in  which  all  assertions  (accurate,  current,  consistent, 
complete)  hold. 

30.  Data  Model.  In  a  database,  the  user's  logical  view  of  the  data  in  contrast  to  the 
physically  stored  data  or  storage  structure.  The  organization  of  data  described  in  a  manner 
that  reflects  the  information  structure  of  an  enterprise  (DoD  8320.1 -M).  (See  also  Modeling  - 
Data  Models) 

31  Data  Object.  A  term  used  to  refer  to  either  an  entity  or  an  attribute. 

32.  Data  Requirements.  A  specification  of  data  needed  to  support  a  business  function. 

Data  models  and  data  element  characteristics  (e.g.,  name  and  definition)  required  in  proposals 
for  standard  data  elements  are  used  to  document  what  data  the  organization  needs  to  support 
its  business  or  mission. 

33.  Data  Steward.  The  person  or  group  that  manages  the  development,  approval,  creation, 
and  use  of  data  associated  with  a  specific  prime  word  managed  within  a  specified  functional 
area.  It  is  the  data  steward's  responsibility  to  support  cross-function  and  review  of  the  data  so 
they  can  be  used  to  satisfy  data  requirements  throughout  the  enterprise.  (DoD  8320.1-M-l) 

34  Data  Structure.  The  logical  relationships  that  exist  among  units  of  data  and  the 
descriptive  features  defined  for  those  relationships  and  data  units;  an  instance  or  occurrence  of 
a  data  model.  (NBS  Spec  Pub  500-152) 

35.  Database.  A  collection  of  interrelated  data,  often  with  controlled  redundancy, 
organized  according  to  a  schema  to  serve  one  or  more  applications;  the  data  are  stored  so  that 
they  can  be  used  by  different  programs  without  concern  for  the  data  structure  or  organization. 
A  common  approach  is  used  to  add  new  data  and  to  modify  and  retrieve  existing  data.  (FIPS 
Pub  11-3) 

36.  Database  Administrator  fDBA).  A  person  or  group  that  enforces  policy  on  "how," 
"where,"  and  "in  what  manner"  data  are  stored  and  maintained  in  each  database.  Provides 
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information  to  the  data  administrator  on  organizational  use  of  data  within  the  subject  database. 
(DoDD  8000.1) 


37.  Database  Management  System.  A  computer-based  system  used  to  establish,  make 
available,  and  maintain  the  integrity  of  a  database,  that  may  be  invoked  by  nonprogrammers 
or  by  application  programs  to  define,  create,  revise,  retire,  interrogate,  and  process 
transactions;  and  to  update,  back  up,  recover,  validate,  secure,  and  monitor  the  database. 

(FIPS  Pub  11-3) 

38.  Degree.  (See  Cardinality) 

39.  Dependent  Entity.  An  entity  that  depends  on  the  existence  of  one  or  more  other 
entities  for  its  identification.  The  entities  on  which  it  depends  can  be  either  independent  or 
dependent.  The  primary  key  for  a  dependent  entity  contains  foreign  keys  contributed  by  the 
entities  on  which  it  depends.  There  are  three  basic  types  of  dependent  entities:  category 
entity,  attributive  entity,  and  associative  entity. 

40.  Derived  Data.  Derived  attributes  represent  the  results  of  computational  operations 
performed  on  other  attributes.  The  computations  may  involve  algorithms  supported  by  two  or 
more  attributes  within  a  single  entity  instance,  or  algorithms  summarizing  attribute  values 
across  multiple  entity  instances  within  a  single  entity  or  across  multiple  entities. 

41.  Domain.  The  set  of  permissible  data  values  from  which  actual  values  are  taken  for  a 
particular  attribute  or  specific  data  element.  In  a  relational  database,  all  of  the  permissible 
tuples  for  a  given  relation.  (FIPS  Pub  11-3) 

42.  Enterprise.  The  highest  level  in  an  organization;  includes  all  missions  and  functions. 

43.  Enterprise  Model.  A  high-level  model  of  an  organization's  mission,  functions,  and 
information  architecture  necessary  for  running  the  enterprise.  The  model  consists  of  an 
activity  model  and  a  data  model. 

44.  Entity.  An  object  about  which  the  organization  wishes  to  collect  information;  a 
person,  place,  thing,  event,  or  concept  of  importance  to  the  enterprise  that  is  singular, 
exclusive,  and  identifiable.  An  entity  is  also  known  as  an  entity  type  or  entity  class. 

45.  Entity  Class.  (See  Entity) 

46.  Entity  Type.  (See  Entity) 

47.  Entity  Relationship  Diagram  lERDl.  The  graphic  representation  of  a  data  model  that 
shows  the  major  entities,  entity  relationships,  and  often  the  attributes  that  support  all  or  part 
of  an  enterprise. 
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48.  External  Schema.  (See  Schema  -  External  Schema) 


49.  Facilitator.  A  person  whose  declared  role  is  to  guide  a  meeting  toward  its  objective 
(e.g.,  development  of  activity  and  data  models  for  an  organization). 

50.  Foreign  Key.  An  attribute  or  group  of  attributes  in  an  entity  that  are  inherited  from 
another  entity  through  a  relationship.  Foreign  keys  show  relationships  between  child  or 
dependent  entities  and  parent  entities.  The  foreign  key  may  or  may  not  become  part  of  the 
primary  key  of  the  child  or  dependent  entity. 

51  Fully  Attributed  Model.  A  third  normal-form  information  model  that  includes  all 
entities,  attributes,  relationships,  and  integrity  rules  needed  by  the  functional  activity  being 
modeled. 

52  Functional  Activity.  The  primary  subdivision  of  a  functional  area,  made  up  of  a 
collection  of  processes  that  can  be  managed  together  using  policies  and  procedures  not 
specifically  applicable  to  other  functional  activities  within  the  functional  area.  (DoD 
8320.1-M) 

53  Functional  Area.  A  functional  area  encompasses  the  scope  (the  boundaries)  of  a  set  of 
related  functions  and  data  for  which  an  OSD  Principal  Staff  Assistant  or  the  Chairman  of  the 
Joint  Chiefs  of  Staff  has  DoD-wide  responsibility,  authority,  and  accountability.  A  functional 
area  (e.g.,  personnel)  is  composed  of  one  or  more  functional  activities  (e.g.,  recruiting),  each 
of  which  consists  of  one  or  more  functional  processes  (e.g.,  interviews).  Also  known  as  a 
business  area.  DoDD  8000.1  (reference(c)). 

54.  Functional  Area  Data  Model.  Business  area  model  of  data  requirements  that  support 
specific  information  needs  within  or  between  the  major  functional  areas  of  an  enterprise.  It  is 
used  for  business  area  analysis  to  support  functional  area  integration. 

55.  Fundamental  Entity.  (See  Independent  Entity) 

56.  General  Domain.  A  specified  range  of  values  a  data  element  is  permitted  to  have.  In 
general,  these  domains  are  too  large  to  be  completely  enumerated  easily.  For  example:  The 
general  domain  of  a  data  element  named  "PERSON  BIRTH  DATE"  is  any  date  falling  in  the 
range  1  Jan  1850  through  the  current  date.  Although  the  domain  is  constrained  (e.g.,  possibly 
to  refer  to  only  people  who  are  currently  alive),  there  is  a  large  number  of  values. 

57.  Generalization  Entity.  (See  Generic  Parent) 

5g  Generic  Element.  A  generic  element  is  the  part  of  a  data  element  that  establishes  a 
structure  and  limits  the  allowable  set  of  values  of  a  data  element.  A  generic  element  has  no 
functional  or  application  context  other  than  to  define  a  general  class  of  data  and  ensure 
consistency  in  structure  and  domain.  (DoD  8320.1-M-l) 
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59.  Generic  Parent.  The  entity  at  the  top  of  any  level  of  a  hierarchy  of  entities.  The 
parent  entity  of  a  categorization  relationship. 

60.  Group  Attribute.  An  attribute  that  is  a  collection  of  other  attributes  called  constituents. 

61.  IDEF.  (See  Integrated  Computer  Aided  Manufacturing  Definition) 

62.  IDEFO.  A  standard  methodology  used  for  modeling  an  enterprise's  processes  and 
activities. 

63.  IDEF IX.  A  standard  methodology  used  for  modeling  an  enterprise's  data 
requirements. 

64.  Identifying  Relationship.  A  relationship  in  which  all  primary  key  attributes  of  the 
parent  entity  become  part  of  the  primary  key  of  the  child  entity. 

65.  Independent  Entity.  An  object  of  interest  to  the  enterprise  that  can  be  identified  using 
primary  key  attributes  that  characterize  the  object  without  referring  to  Foreign  Keys  migrated 
from  any  other  entity.  Also  known  as  a  fundamental,  principal,  primary,  independent  entity 
class,  and  supertype. 

66.  Independent  Entity  Class.  (See  Independent  Entity) 

67.  Information.  Any  communication  or  reception  of  knowledge  through  facts,  data,  or 
opinions,  including  numerical,  graphic,  or  narrative  forms,  whether  oral  or  maintained  in  any 
medium  including  computerized  databases,  paper,  microform,  or  magnetic  tape.  The  meaning 
that  is  assigned  to  data  by  persons  who  know  the  conventions  used  in  its  representation. 

68.  Information  Engineering.  A  disciplined  methodology  that  creates  an  organization-wide 
architectural  framework  for  application  and  database  development. 

69.  Information  Model.  A  model  that  represents  the  processes,  entities,  information  flows, 
and  elements  of  an  organization  and  all  relationships  between  these  factors.  DoD  8320. 1-M 
(reference  (d)). 

70.  Information  System.  The  organized  collection,  processing,  maintenance,  transmission, 
and  dissemination  of  information  in  accordance  with  defined  procedures,  whether  automated 
or  manual.  (DoD  Directive  5200.28,  as  modified  by  OMB  Cir  A- 130) 

71.  Integrated  Computer-Aided  Manufacturing  Definition  (IDEF).  A  technique  used  for 
modeling  an  enterprise's  processes  and  data. 
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72.  Integrity  Constraint.  A  statement  in  an  information  model  that  specifies  one  or  more 
assertions  regarding  how  specific  instances  of  data  objects  are  captured  and  managed. 


73.  Internal  Schema.  (See  Schema  -  Internal  Schema) 

74.  Intersecting  Entity.  (See  Entity  -  Dependent,  and  Associative  Entity) 

75.  Kev  Attribute.  (See  Attribute) 

76.  Logical  Data  Model.  A  model  of  the  data  that  represents  the  inherent  structure  of  that 
data  and  is  independent  of  individual  applications  of  the  data  and  also  of  the  software  or 
hardware  mechanisms  employed  to  represent  and  use  the  data. 

77.  Metadata.  Information  describing  the  characteristics  of  data;  data  or  information  about 
data;  descriptive  information  about  an  organization's  data,  data  activities,  systems,  and 
holdings.  (NBS  Spec  Pub  500-152) 

78.  Methodology.  The  principles,  practices,  etc.,  of  orderly  thought  or  procedure  applied 
to  a  particular  branch  of  learning  (i.e.,  data  modeling).  A  set  of  standards  and  procedures 
used  to  guide  the  development  of  a  data  model. 

79.  Modeling.  Application  of  a  standard,  rigorous,  structured  methodology  to  create  and 
validate  a  physical,  mathematical,  or  otherwise  logical  representation  of  a  system,  entity, 
phenomenon,  or  process. 

a.  Activity  Models.  Models  of  the  processes  that  make  up  the  functional  activity 
showing  inputs,  outputs,  controls,  and  mechanisms  through  which  the  processes  of  the 
functional  activity  are  (or  will  be)  conducted. 

b.  Data  Model.  In  a  database,  the  user's  logical  view  of  the  data  in  contrast  to  the 
physically  stored  data  or  storage  structure.  A  description  of  the  organization  of  data  in  a 
manner  that  reflects  the  information  structure  of  an  enterprise. 

80.  Nature.  (See  Cardinality) 

81.  Non-identifying  Relationship.  A  relationship  in  which  the  primary  key  of  the  parent 
entity  does  not  become  part  of  the  primary  key  of  the  child  entity. 

82.  NonKev  Attribute.  (See  Attribute) 

83.  Non-standard  Data  Element.  Any  data  element  that  exists  in  a  system  or  application 
program  and  does  not  conform  to  the  conventions,  procedures,  or  guidelines  established  by 
the  organization.  (DoD  8320.1-M-l) 
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84.  Non-specific  Relationship.  A  relationship  in  which  no  foreign  keys  are  contributed, 
and  in  which  many  of  one  entity  are  related  to  many  of  another  entity. 

85.  Normalization.  The  process  of  removing  inaccurate,  inconsistent,  and/or  overly 
complex  assertions  from  an  information  model. 

86.  Null.  Having  no  value.  An  attribute  can  have  a  null  value  if  the  value  is  unknown  or 
the  value  is  not  applicable. 

87.  Parent  Entity.  The  entity  from  which  a  relationship  receives  a  foreign  key. 

88.  Physical  Data  Model.  A  representation  of  the  technologically  independent 
requirements  in  a  physical  environment  of  hardware,  software,  and  network  configurations 
representing  them  in  the  constraints  of  an  existing  physical  environment.  (FIPS  Pub  1 1-3) 

89.  Primary  Entity.  (See  Entity  -  Independent  Entity) 

90.  Primary  Key.  An  attribute  or  group  of  attributes  chosen  to  uniquely  identify  an  entity. 
Primary  keys  are  never  null.  Each  entity  or  entity  class  has  one  and  only  one  primary  key. 

A  primary  key  is  migrated  through  relationships  to  become  a  foreign  key  in  child  or 
dependent  entities.  Primary  keys  are  also  known  as  determinants  or  identifiers. 

91.  Prime  Word.  A  word  included  in  the  name  of  a  data  entity  that  represents  the  logical 
data  grouping  (in  the  logical  data  model)  to  which  it  belongs.  (NBS  Spec  Pub  500-149) 

92.  Principal  Entity.  (See  Entity  -  Independent  Entity) 

93.  Relationship.  A  meaningful  association  between  two  or  more  entities.  In  semantic 
data  modeling,  relationships  are  labeled  as  verbs  or  verb  phrases.  For  example: 

EQUIPMENT  ITEM  supports  WEAPON  SYSTEM;  WEAPON  SYSTEM  is  supported  by 
EQUIPMENT  ITEM.  A  connection  relationship  has  cardinality  and  may  be  either  a  Specific 
Relationship  or  a  Nonspecific  Relationship  (See  Specific  Relationship  and  Nonspecific 
Relationship).  Basic  components  of  a  relationship  are  The  Relationship  Name,  Degree  of 
Cardinality,  and  Nature  of  Cardinality.  (See  Relationship  Name  and  Cardinality) 

94.  Relationship  Name.  Always  a  verb  or  verb  phrase;  the  label  given  to  a  relationship. 
The  name  of  the  relationship  reflects  the  activity  or  function  that  takes  place  between  two 
entities.  When  read  in  sequence  (entity-relationship-entity),  a  statement  is  made  about  the 
organization  operations.  Attributive  and  category  entities  will  always  be  associated  with  at 
least  one  independent  entity;  and  an  associative  entity  will  have  a  minimum  of  two  related 
parent  entities.  Also  known  as  a  relationship  label. 

95.  Schema.  Descriptive  representation  of  data  and/or  data  requirements  that  describe 
conceptual,  internal,  or  external  views  of  information/data  needs. 
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a  Conceptual  Schema.  A  descriptive  representation  of  data  and  data  requirements 
that  support  the  "logical"  view  or  data  administrator's  view  of  the  data  requirement.  This 
view  is  represented  as  a  semantic  model  of  the  information  that  is  stored  about  objects  of 
interest  to  the  functional  area.  This  view  is  a  single  integrated  definition  of  the  data  and  is 
unbiased  toward  any  single  application  of  data  and  is  independent  of  how  the  data  are 
physically  stored  or  accessed.  An  attributed,  normalized  data  model  is  also  referred  to  as 
conceptual  schema.  The  conceptual  schema  is  used  for  data  standardization  and  database 
design.  The  conceptual  schema  is  used  to  support  application  integration.  It  provides  a 
consistent  definition  of  the  meanings  and  interrelationships  of  the  data  used  to  integrate, 
share,  and  manage  the  integrity  of  data  within  and  across  applications. 

b  Internal  Schema.  A  descriptive  representation  of  data  and  data  requirements  as 
they  are  physically  stored  and  includes  all  aspects  of  the  environment  in  which  a  database  is 
to  reside.  The  internal  schema  is  often  referred  to  as  the  "physical"  view  or  database 
administrator's  view  of  the  data  requirement.  This  view,  also  known  as  a  physical  database 
design,  is  described  by  the  data  definition  language  (DDL)  and  physical  storage  methods  used 
to  implement  the  data  requirements  described  under  a  conceptual  schema.  The 
denormalization  of  conceptual  schema  data  requirements  may  occur  in  connection  with  system 
performance  and  technological  constraints.  Any  denormalization  must  be  coordinated  with 
the  manager  of  the  conceptual  schema  (i.e.,  Data  Administrator). 

c  F.xternal  Schema.  A  descriptive  representation  of  data  and  data  requirements 
that  supports  the  "user"  view  or  application  view  of  the  data.  This  view  is  represented  by 
reports,  transactions,  and  screens  that  are  designed  to  support  the  individual  worker  in  the 
performance  of  tasks  or  activities.  The  external  schema  may  differ  from  the  conceptual 
schema  upon  which  it  is  based:  some  entities,  attributes,  or  relationships  may  be  omitted, 
renamed,  or  otherwise  transformed.  The  design  and  development  of  an  external  schema  is 
equivalent  to  the  design  and  development  of  the  human-computer  interface  (HCI)  for  the 
automatic  information  system  (AIS)  and  supports  integration  at  the  local  and  personal  levels 
of  the  information  management  integration  architecture. 

96.  Secondary  Entity.  (See  Category  Entity) 

97.  Specific  Domain.  The  precise  set  of  possible  values  for  a  data  element  (attributes). 

98.  Specific  Relationship.  A  relationship  between  two  entities  in  which  dependency  can 
be  determined  and  keys  migrated  from  the  parent  to  the  child.  The  cardinality  from  the 
parent  to  child  may  vary,  but  the  child  may  be  related  to  one  and  only  one  parent.  Specific 
relationships  are  the  only  type  permitted  at  the  key-based  and  fully  attributed  levels.  DoD 
IDEF  Workshop  Participant  Guide  (reference  (a)). 

99.  Standard  Data  Element.  A  data  element  that  has  been  approved  formally  in 
accordance  with  the  organization's  data  element  standardization  procedures.  (DoD  8320. 1-M- 

1) 
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100.  Strategic  Data  Model.  High-level  model  of  data  requirements  that  support  the 
information  needs  across  the  corporate  enterprise.  It  is  used  for  strategic  data  planning  and 
policy  purposes. 

101.  Subentitv.  (See  Category  Entity) 

102.  Supertvpe  Entity.  (See  Entity  -  Independent  Entity) 

103.  Technique.  The  working  methods  or  manner  in  which  rules,  syntax,  semantics  are 
applied  within  a  given  methodology. 

104.  Tuple.  A  row  in  a  relation. 

105.  View.  An  external  schema  comprising  entities,  attributes,  and  relations  retrieved  or 
derived  from  one  or  more  base  internal  schema  or  a  conceptual  schema. 
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ABBREVIATIONS  AND/OR  ACRONYMS 


AIS 

Automatic  Information  System 

ASD 

Assistant  Secretary  of  Defense 

BPR 

Business  Process  Reengineering 

C3I 

Command,  Control,  Communications  and  Intelligence 

CDAd 

Component  Data  Administrator 

Cfdad 

Component-Level  Expert 

CIM 

Center  for  Information  Management 

DAd 

Data  Administrator 

DAPMO 

Data  Administration  Program  Management  Office 

DASD 

Deputy  Assistant  Secretary  of  Defense 

DASP 

Data  Administration  Strategic  Plan 

DDL 

Data  Definition  Language 

DDRS 

Defense  Data  Repository  System 

DMP 

Data  Management  Plan 

DoD 

Department  of  Defense 

ERD 

Entity  Relationship  Diagram 

FAPM 

Functional  Activity  Program  Manager 

FDAd 

Functional  Data  Administrator 

FIM 

Functional  Information  Manager 

HCI 

Human  Computer  Interface 

IDEF1X 

Integration  Definition  for  Information  Modeling 

IM 

Information  Management 

IRM 

Information  Resource  Management 

NIST 

National  Institute  of  Standards 

OSD 

Office  of  the  Secretary  of  Defense 

PSA 

Principal  Staff  Assistant 

SME 

Subject  Matter  Expert 

INF 

First  Normal  Form 

2NF 

Second  Normal  Form 

3NF 

Third  Normal  Form 

4NF 

Fourth  Normal  Form 

5NF 

Fifth  Normal  Form 
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CHAPTER  1 


GENERAL  INFORMATION 


A.  INTRODUCTION 

1 .  The  procedures  outlined  in  this  document  provide  the  structure  to  extend,  approve, 
and  maintain  the  Department  of  Defense  (DoD)  Enterprise  Data  Model.  Results  of  implementing 
these  procedures  will  be  the  standardization  of  data  entities  as  prime  words  and  identification  and 
entry  of  model  based  data  elements  (attributes)  ready  for  standardization  in  accordance  with  DoD 
8320.1-M-l  (reference  (b)). 

2.  The  DoD  Enterprise  Model  is  a  representation  of  the  activities  and  data  of  the 
DoD.  The  model  embodies  top-level  processes  and  standard  data  interfaces  relevant  to  every 
DoD  major  mission  and  function.  It  is  the  basis  for  defining,  coordinating,  and  integrating  DoD 
missions  and  functions. 

3.  The  DoD  Enterprise  Model  is  needed  to  support  the  defense  mission  from 
warfighting  to  acquisition  and  logistics.  It  will  enable  the  Department's  leaders  and  managers  to 
better  understand  and  direct  their  areas  of  responsibility  and  to  integrate  business  process 
reengineering  initiatives  within  and  across  functional  and  organizational  boundaries. 

4.  The  initial  version  of  the  DoD  Enterprise  Data  Model  was  developed  in 
conjunction  with  the  activities  of  the  DoD  Enterprise  Model  through  comprehensive  analysis  of 
the  top-level  processes  and  a  thorough  review  of  the  fundamental  guiding  documents  for  the 
Department.  The  DoD  Enterprise  Data  Model  extends  down  to  the  level  of  attributes  and 
relationships  in  concert  with  the  definition  of  more  detailed  DoD  activities.  Expansion  and 
maintenance  of  the  DoD  Enterprise  Data  Model  is  performed  and  managed  by  the  DoD  Data 
Administration  Program  Management  Office  (DAPMO). 

5.  Functional  area  and  Component  data  modeling  and  associated  information 
requirements  are  the  driving  force  behind  expansion  and  maintenance  of  the  DoD  Enterprise  Data 
Model.  These  modeling  efforts  drive  DoD  data  element  standardization  through  identification, 
cross-functional  review,  and  approval  of  extensions  to  the  DoD  Enterprise  Model  from  which  data 
standards  proposals  originate. 

6.  Functional  area  and  Component  modeling  efforts  are  being  performed  in 
accordance  with  required  DoD  activities  such  as  business  process  reengineering  (BPR)  and 
migration  system  activities;  required  legacy  system  reengineering;  modification,  and/or 
maintenance  activities;  and  as  deemed  necessary  by  the  various  functional  areas  and  Components 
within  DoD.  Requirements  for  compliance  with  the  DoD  Data  Administration  procedures  are 
discussed  under  Applicability  and  Scope  in  8320.1  (reference  (e)).  Additional  conformance 
requirements  specific  to  data  standardization  are  discussed  under  Applicability  and  Scope  in 
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8320.1- M-l  (reference  (b)).  Procedures  for  checking,  measuring,  and  ensuring  data 
standardization  compliance  in  automatic  information  systems  (AISs)  are  specified  in  DoD 
Directives  8120.1  (reference  (f))  and  8120.2  (reference  (g)). 

7.  The  DoD  Enterprise  Data  Model  development,  approval,  and  maintenance  process 
integrates  information  requirements,  as  they  are  identified,  into  one  cohesive  and  coherent 
information  frame  of  reference  for  all  of  DoD.  The  fundamental  objective  of  the  DoD  Enterprise 
Data  Model  is  to  provide  the  basic  data  architecture  for  effective  administration  of  data  needed 
across  the  Department. 

B.  PURPOSE 

This  manual  promulgates  the  procedures  for  developing,  approving,  and  maintaining  the 
DoD  Enterprise  Data  Model.  DoD  Directive  8320.1,  "DoD  Data  Administration"  (reference  (e)) 
established  policy  and  authorized  the  implementation  guidelines  as  set  forth  in  DoD  Manual 

8320. 1- M  (reference  (d)). 

C.  SCOPE  AND  APPLICABILITY 

1.  The  scope  and  applicability  are  identical  to  that  described  in  DoD  Directive 
8320.1,  "DoD  Data  Administration"  (reference  (e)). 

2.  Systems  not  required  to  conform  to  DoD  data  administration  procedures  (such  as 
prototype  system  development  efforts)  should  consider  voluntary  application  of  this  and  other 
8320.1  procedures  in  the  early  stages  of  development  to  whatever  extent  possible.  This  is 
especially  true  if  they  expect  to  eventually  implement  these  systems  in  a  production  environment, 
or  if  there  is  any  possibility  of  future  data  sharing  with  other  DoD  AISs.  Early  compliance  will 
save  time,  money,  and  other  resources  in  downstream  AIS  life-cycle  management  activities.  An 
organization's  ability  to  obtain  future  funding  for  development  and  maintenance  on  these  and 
other  DoD  AISs  could  be  negatively  affected  by  a  lack  of  effort  within  their  organization  to 
comply  with  these  and  other  DoD  data  administration  procedures. 

D.  OBJECTIVES 

The  objective  of  DoD  data  administration  is  to  support  the  development  and  management 
of  useful,  suitable,  available,  and  accessible  information  to  enable  the  successful  execution  of  the 
missions  of  the  Department.  The  objectives  are  to: 

1.  Develop  a  DoD  Enterprise  Data  Model  that  depicts  overall  DoD  mission  needs  and 
supports  operational  capabilities  requiring  the  collection,  storage,  and  exchange  of  data. 

2.  Develop  data  elements  for  standardization  through  data  modeling  efforts. 

3.  Create  a  base  of  shared  information  through  the  DoD  Enterprise  Data  Model  and 
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standard  data  structures  and  elements.  This  will  enable  functional  and  technical  personnel  to 
perform  their  tasks  in  an  integrated,  effective,  and  efficient  manner. 


1  -  3 


CHAPTER  2 


ROLES  AND  RESPONSIBILITIES 


A.  INTRODUCTION 


Expansion  of  the  DoD  Enterprise  Data  Model  and  development  of  DoD  data  standards 
through  functional  area  data  modeling  is  supported  by  many  organizations.  This  chapter 
identifies  the  key  participants  who  contribute  to  the  DoD  Enterprise  Data  Model  development, 
approval,  maintenance,  and  integration  process  and  summarizes  their  responsibilities  within 
this  process.  Additional  DoD  Data  Administration  responsibilities  discussed  below  can  be 
found  in  DoD  Directive  8320.1  (reference  (e))  and  DoD  8320. 1-M  (reference  (d)). 

B.  ROLES 

1.  Model  Originator 

A  model  originator  is  the  DoD  organization  who  prepares  and  submits  a  model 
to  update/extend  the  DoD  Enterprise  Data  Model. 

2.  Functional  Data  Administrator  (FDAd) 

a.  FDAds  represent  various  functional  area  views  within  the  DoD.  They 
are  responsible  for  ensuring  that  models  being  developed,  reviewed,  and  approved  as 
extensions  to  the  DoD  Enterprise  Data  Model  are  functionally  correct.  The  FDAd  is  also 
tasked  to  integrate  new  and  modified  functional  area  data  models  within  their  functional  area 
data  architecture  with  the  DoD  Enterprise  Data  Model. 

b.  FDAds  are  assigned  functional  areas  by  Office  of  the  Secretary  of 
Defense  Principal  Staff  Assistants  (OSD  PSAs),  unless  the  functional  areas  are  represented  by 
OSD  PSAs  themselves.  FDAds  work  directly  with  other  FDAds,  Component  Data 
Administrators  (CDAds),  the  DoD  Data  Administrator  (DoD  DAd),  OSD  PSAs,  other  subject 
matter  experts  (SMEs),  and  designated  representatives,  to  coordinate  and  perform  data  model 
development,  review,  maintenance,  and  integration  tasks. 

c.  FDAds  who  are  assigned  functional  data  stewardship  responsibilities 
coordinate  functional  area  model  development,  review,  integration,  and  maintenance  activities 
prior  to  the  formal  review  process.  They  also  work  with  the  DoD  DAd  and  the  DAPMO  to 
support  model  review,  approval,  and  maintenance  during  the  formal  review  process  and 
functional  integration,  expansion,  and  maintenance  of  the  DoD  Enterprise  Data  Model. 

d.  There  are  three  types  of  functional  data  stewards: 
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(1) 


Proposal  Package  Functional  Data  Steward 


An  FDAd  assigned  to  coordinate  the  informal  review  of  a 
nronosal  package  to  chair  associated  rapid  data  standardization  guidance  collaborative 
sessions,  and  to  work  with  the  DoD  DAd  and  designated  representatives  during  the  formal 

review  process. 

(2)  F.ntitv  Functional  Data  Steward 

An  FDAd  assigned  to  support  the  proposal  package  functional 
data  steward  with  coordination,  qnestions,  decision  making,  and  issue  resolution  associated 
with  a  given  entity  in  a  proposal  package. 

(3)  Attribute  Functional  Data  Steward 

An  FDAd  assigned  to  support  the  entity  and  proposal  package 
functional  data  stewards  with  coordination,  questions,  decision  making,  and  issue  resolution 
associated  with  a  single  attribute  in  the  proposal  package. 

e.  Functional  data  stewardship  is  initially  assigned  by  either  the  model 
originator  or  representatives  of  a  rapid  data  standardization  collaborative  session.  e 
functional  data  steward  assigned  to  a  proposal  package,  entity,  or  attribute  should  be  the 
FDAd  who  is  assigned  responsibility  for  the  functional  area  that  creates  and/or  manages  data 
associated  with  the  particular  proposal  package,  entity,  or  attribute. 

(1)  The  same  FDAd  should  be  assigned  functional  data  steward 
responsibilities  for  all  entity  instances  and  attributes  associated  with  a  given  prime  word. 

(2)  A  single  FDAd  can  be  assigned  functional  data  stewardship 
responsibilities  for  multiple  proposal  packages,  entities,  and  attributes. 

(3)  Management  of  each  entity  will  be  assigned  to  a  single 
functional  data  steward  (functional  area),  even  if  some  of  the  attributes  within  it t  are assigned 
[0  different  attribute  functional  data  stewards.  The  entity  functional  data  steward  will 
coorftaatoveral.  review  and  maintenance  of  the  entity  while  worktng  with  the  various 
associated  attribute  functional  data  stewards. 

(4)  A  current  list  of  FDAd  functional  areas  of  responsibility  is 
available  in  the  Defense  Data  Repository  System  (DDRS)  and  from  the  DoD  DAd. 

f  The  stewardship  assignments  are  validated  during  subsequent  review 

and  integration  activities.  If  issues  associated  with  data  steward  assignment  arise  that  cannot 
reeved  they  should  be  submitted  to  the  DoD  DAd.  All  functional  data  stewardship 
assignmem'questions  and  issues  submitted  to  the  DoD  DAd  will  be  resolved  wtthin  48  hours 
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of  identification  and  documentation.  The  DoD  DAd  is  the  final  authority  on  data  stewardship 
assignment  issues. 

3.  Component  Data  Administrator  (CD Ad) 

CDAds  represent  cross-functional  views  of  information  for  a  given  DoD 
Component,  which  includes  the  DoD  services  (Army,  Navy,  Air  Force,  etc..)  and  the  specified 
and  unified  commands.  CDAds  are  responsible  for  ensuring  that  models  being  developed, 
reviewed,  and  approved  as  extensions  to  the  DoD  Enterprise  Data  Model  are  functionally 
correct  and  are  properly  integrated  with  component-level  data  models  and  the  DoD  Enterprise 
Data  Model.  CDAds  are  selected  by  each  Component  head.  CDAds  work  directly  with  other 
CDAds,  FDAds,  the  DoD  DAd,  OSD  PSAs,  SMEs,  and  designated  representatives  to  support 
data  model  development,  review,  maintenance,  and  integration. 

4.  Department  of  Defense  Data  Administrator  ('DoD  DAdl 

The  DoD  DAd  is  responsible  for  implementing  DoD  procedures  for  data 
modeling  and  integration,  data  standardization,  data  security,  data  quality  assurance,  and 
database  operations.  The  DoD  DAd  and  designated  representatives  within  the  DAPMO 
support  informal  reviews  and  are  responsible  for  rapid  data  standardization  collaborative 
sessions,  DoD  Enterprise  Data  Model  integration,  and  technical  and  cross-functional  reviews. 
The  DoD  DAd  is  selected  by  the  Assistant  Secretary  of  Defense  for  Command,  Control, 
Communications  and  Intelligence  (ASD(C3I)). 

5.  Data  Administration  Program  Management  Office  (DAPMO)  Representative 

The  DAPMO  office  supports  the  DoD  DAd  with  procedure  development  and 
implementation,  model  review,  integration,  data  standardization,  publication  of  the  DoD 
Enterprise  Data  Model,  physical  database  design,  and  requirements  and  training  for  the 
DDRS.  DAPMO  plays  a  critical  role  in  the  DoD  data  modeling  and  standardization  processes 
while  supporting  related  activities  associated  with  migration  system  projects,  database 
development  efforts,  and  the  DoD  BPR  process. 

6.  Subject  Matter  Expert  (SME) 

SMEs  are  functional  and  technical  experts  within  DoD  who  support  the  design, 
development,  review,  implementation,  and  maintenance  of  DoD  data  products.  SMEs  include 
Functional  Activity  Program  Managers  (FAPMs),  DoD  Functional  Information  Managers 
(FIMs),  Technical  Information  Managers,  component-level  experts  (Cfdads),  functional  area 
system  and/or  database  administrators/experts,  Component  system  and/or  database 
administrators/experts,  registered  users  of  standard  DoD  data  products,  OSD  PSAs,  FDAds, 
and  CDAds.  SMEs  can  also  be  designated  representatives  for  any  of  these  organizations. 
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7. 


Functional  Activity  Program  Managers  (FAPM) 


FAPMs  are  designated  representatives  of  the  OSD  PSAs  and  the  Chairman, 
Joint  Chiefs  of  Staff.  FAPMs  work  with  the  FDAds  and  OSD  PSAs  to  support  Business 
Process  Improvement  (BPI),  modeling,  and  data  standardization.  FAPMs  are  SMEs  for  the 
functional  activities  they  represent. 

8.  Office  of  the  Secretary  of  Defense  Principal  Staff  Assistant  (OSD  PSA) 

OSD  PSAs  are  responsible  for  functional  area  model  adherence  to  DoD  Data 
Administration  policy,  procedures,  and  standards.  OSD  PSAs  designate  FDAds  for  each 
functional  area  for  which  they  are  responsible  and  support  them  throughout  the  data  model 
development,  review,  and  maintenance  process.  They  also  support  the  FDAds  and  the  DoD 
DAd  during  integration  of  functional  area  data  models  into  the  DoD  Enterprise  Data  Model. 

9.  Deputy  Assistant  Secretary  of  Defense  for  Information  Management 

(DASDflM)} 


DASD(IM)  develops  policy,  procedures,  and  related  standards  for  Information 
Resource  Management  (IRM),  including  data  administration,  and  makes  recommendations  to 
the  ASD(C3I)  for  approval.  During  functional  area  data  model  review  and  integration  into  the 
DoD  Enterprise  Data  Model,  DASD(IM)  works  with  the  OSD  PSAs  and  the  DoD  DAd  to 
resolve  issues  that  cannot  be  resolved  in  the  formal  review  process  by  FDAds,  CDAds,  DoD 
DAd,  and  associated  SMEs.  When  an  issue  cannot  be  resolved  at  DASD(IM)  level, 
DASD(IM)  reports  to  ASD(C3I)  to  communicate,  coordinate,  and  return  a  resolution. 

10.  Assistant  Secretary  of  Defense  for  Command,  Control,  Communications  and 
Intelligence  (ASD(C3I)) 

ASD(C3I)  is  the  designated  senior  information  management  official  within 
DoD  (DoD  Directive  5137.1,  reference  (1)).  ASD(C3I)  works  with  DASD(IM)  to  resolve 
issues  for  which  a  resolution  cannot  be  reached  during  the  cross-functional  review  or  by  the 
DASD(IM).  ASD(C3I)  has  final  authority  on  all  issues. 

C.  RESPONSIBILITIES 

Each  category  of  proponents/participants  that  contribute  to  development,  approval,  and 
maintenance  of  the  DoD  Enterprise  Data  Model  has  a  specific  set  of  responsibilities 
associated  with  this  process.  These  responsibilities  are  discussed  below. 

1.  Model  Originator 

a.  Proposes  to  extend  or  update  the  DoD  Enterprise  Data  Model  by 
preparing  a  functional  area  data  model  proposal  package  for  submission. 
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b.  Submits  the  functional  area  data  model  proposal  package  to  their 
respective  FDAd  or  CDAd  (depending  on  the  model  content),  in  accordance  with  functional 
or  component  procedures.  This  begins  the  data  model  review  process. 

c.  Works  with  the  FDAd  or  CDAd  to  ensure  functional  and  technical 
compliance  and  to  prepare  the  model  for  informal  review. 

d.  Works  with  proposal  package  data  stewards  to  answer  functional 
questions  and  to  help  resolve  functional  and  technical  issues  during  model  review  and 
integration  into  the  DoD  Enterprise  Data  Model. 

e.  Supports  modification  of  the  model  and  the  associated  proposal 
package(s)  as  needed  based  on  feedback  from  the  review  process. 

2.  Functional  Data  Administrator  (FDAd) 

a.  Proposes  functional  area  projects  for  rapid  data  standardization 
collaborative  session  support. 

b.  Co-chairs  and  supports  rapid  data  standardization  collaborative  sessions 
for  projects  within  or  associated  with  the  functional  areas  for  which  they  are  responsible. 

c.  Acts  as  designated  functional  issue  decision-making  authority  during 
rapid  data  standardization  collaborative  sessions. 

d.  Serves  as  advisor  and  reviewer  for  data  models  developed  within  or  in 
support  of  functional  areas  for  which  they  are  responsible. 

e.  Works  with  model  originators,  other  FDAds,  and  SMEs  to  coordinate 
and  integrate  proposed  entities  and  attributes  across  the  functional  areas  for  which  they  are 
responsible.  The  DoD  Enterprise  Data  Model  should  be  considered  during  this  functional 
area  integration. 

f.  Acts  as  or  works  with  functional  data  stewards  to  support  development, 
review,  integration,  and  maintenance  of  functional  area  data  models  being  proposed  to  extend 
or  modify  the  DoD  Enterprise  Data  Model. 

g.  As  a  proposal  package  functional  data  steward: 

(1)  Ensures  that  proposal  packages  adhere  to  functional  and 
technical  requirements  prior  to  submission  for  formal  review. 

(2)  Enters  or  coordinates  entry  of  entities  and  attributes  associated 
with  proposal  packages  into  the  DDRS. 
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(3)  Coordinates  proposal  package  informal  reviews  with  entity  and 
attribute  functional  data  stewards,  other  FDAds,  OSD  PSAs,  CDAds,  the  DoD  DAd,  DAPMO 
representatives,  and  appropriate  SMEs  to  ensure  that  their  views  are  fully  represented. 

(4)  Submits  proposal  packages,  prime  words  (entities)  and  data 
elements  (attributes)  to,  and  supports  the  DoD  DAd  during  the  formal  review  process. 

(5)  Assists  the  DoD  DAd,  and  the  DAPMO  Data  Model  Integration 
Team,  with  the  integration  of  functional  area  models  into  the  DoD  Enterprise  Data  Model. 

(6)  Helps  resolve  issues  associated  with  the  proposed  model  and 
coordinates  resolutions  and  proposed  changes  with  the  submitting  FDAd  or  CDAd  and  other 
model  stakeholders. 

(7)  Tracks  status  of  proposals  and  keeps  the  submitting  FDAd  or 
CDAd  informed  on  progress  and  results. 

(8)  Notifies  the  DoD  DAd  of  actions  taken  against  disapproved 

proposals. 


h.  Supports  proposal  package  functional  data  stewards  when  assigned 
entity/attribute  data  stewardship  responsibilities  by  coordinating  functional  expertise  for  the 
entity(s)/  attribute(s)  they  are  responsible  for. 

i.  Supports  cross-functional  review  of  model  packages  proposing  new, 
modified,  archive  of  and/or  reinstatement  of  data  entities,  associated  attributes,  and 
relationships. 

j.  Functionally  approves  or  disapproves  (standard)  data  under  their 

stewardship. 

k.  Elevates,  to  the  appropriate  OSD  PSAs,  cross-functional  area  issues  that 
cannot  be  resolved  among  affected  FDAds. 

l.  Maintains  functional  area  data  products  in  the  DDRS  and  the  DoD 
Interim  IDEF  Repository. 

m.  Proposes  entities  and  associated  attributes  and  relationships  for  archival. 

n.  Registers  use  of  approved  entities  (prime  words)  and  attributes  (data 
elements)  in  models  and  systems  within  the  functional  areas  for  which  they  are  responsible  in 
the  DDRS. 

o.  Identifies  functional  requirements  not  supported  by  the  DDRS  and 
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submits  the  requirements  to  the  DoD  DAd. 

3.  Component  Data  Administrator  fCDAd) 

a.  Proposes  component-level  projects  for  rapid  data  standardization 
collaborative  session  support. 

b.  Plans  rapid  data  standardization  collaborative  sessions  along  with 
FDAds  and  the  DoD  DAd,  and  supports  them  through  contribution  of  component-level  experts 
(Cfdads  and  SMEs). 


c.  Serves  as  advisor  and  reviewer  during  the  preliminary  review  for  data 
models  developed  within  or  in  support  of  their  Component  organization. 

d.  Submits  component-level  models  to  the  FDAd,  designated  as  the 
proposal  package  functional  data  steward,  for  informal  review  and  submission  to  the  formal 
review  process. 


e.  Works  with  model  originators,  FDAds,  and  SMEs  to  coordinate  and 
integrate  proposed  entities  and  attributes  across  all  functional  areas  within  the  Component 
organization. 


f.  Works  with  FDAds  to  represent  Component  views  and  objectives  during 
informal  proposal  package  reviews. 

g.  Submits  prime  words  (entities)  and  data  elements  (attributes)  for  formal 
cross-functional  review. 

h.  Supports  cross-functional  review  of  model  packages  proposing  new, 
modified,  archive  of  and/or  reinstatement  of  data  entities,  associated  attributes,  and 
relationships. 


i.  Maintains  component-level  data  products  in  the  DDRS  and  the  DoD 
Interim  IDEF  Repository. 

j.  Registers  use  of  approved  entities  (prime  words)  and  attributes  (data 
elements)  in  component-level  models  and  systems  in  the  DDRS. 

k.  Identifies  functional  requirements  not  supported  by  the  DDRS  and 
submit  the  requirements  to  the  DoD  DAd. 

l.  Acts  as  a  liaison  between  functional  areas  within  the  Component, 
FDAds,  and  the  DoD  DAd. 
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4. 


Department  of  Defense  Data  Administrator  (DoD  DAd) 


a.  Selects  data  model  integration  projects  to  be  accomplished  using  rapid 
data  standardization  collaborative  sessions. 

b.  Plans  rapid  data  standardization  collaborative  sessions  along  with 
FDAds  and  CDAds. 

c.  Assigns  DAPMO  representatives  to  help  coordinate  and  support  rapid 
data  standardization  collaborative  sessions,  informal  and  preliminary  proposal  package 
reviews,  formal  technical  and  cross-functional  reviews,  and  integration  of  functional  area  data 
models  into  the  DoD  Enterprise  Data  Model. 

d.  Supports  CDAds  and  FDAds  during  preliminary  and  informal  reviews 

as  needed. 

e.  Validates  data  stewardship  assignments  and  settles  data  stewardship 
assignment  issues. 

f.  Performs  final  technical  review  for  all  models  being  proposed  to  extend 
the  DoD  Enterprise  Data  Model. 

g.  Coordinates  formal  review  of  all  proposals  to  extend  or  update  the  DoD 
Enterprise  Data  Model. 

h.  Resolves  proposal  package  issues  or  works  with  the  DASD(IM)  to 
coordinate  a  resolution  if  the  issue  cannot  be  resolved  between  affected  FDAds,  other 
functional  stakeholders,  and  SMEs. 

i.  Provides  suggestions  to  FDAds  and  CDAds  for  entities  (prime  words) 
and  attributes  (data  elements)  that  should  be  considered  for  archive  based  on  a  lack  of 
registered  implementation  in  the  DDRS. 

j.  Establishes  requirements  for  models,  methods,  tools,  data,  and 
information  technology  to  support  development  of  an  integrated  data  architecture  for  DoD. 

5.  Data  Administration  Program  Management  Office  (DAPMO)  Representative 

a.  Develops  procedures  for  collaborative  modeling,  model  coordination  and 
review,  model  integration,  and  DoD  Enterprise  Model  configuration  management. 

b.  Manages  rapid  data  standardization  collaborative  sessions: 

(1)  Arranges  for  facilities,  facilitator,  data  entity  and  attribute 
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packaging,  and  administrative  support  for  sessions  whenever  possible. 

(2)  Acts  as  an  arbitrator  who  hears  issues  and  rules  on  and  enforces 
procedural  and  technical  data  modeling  and  metadata  rules. 

c.  Supports  the  DoD  DAd  in  performing  technical  reviews  on  all  proposals 
to  extend  the  DoD  Enterprise  Data  Model. 

d.  Technically  approves  or  disapproves  (standard)  data. 

e.  Works  with  the  DoD  DAd  on  technical  issues  that  cannot  be  resolved 
through  coordination  with  FDAds,  CDAds,  and  SMEs. 

f.  Identifies  and  documents  extensions  of  data  topics  into  out-of-scope 
areas  during  reviews  and  collaborative  sessions. 

g.  Identifies  and  documents  data  interchange  and  interface  issues  that  may 
require  additional  data  model  integration  sessions  among  principals. 

h.  Documents  resolutions  to  all  functional  and  technical  issues  that  arise 
during  technical  and  formal  cross-functional  reviews. 

i.  Validates  proposed  integration  of  entities  and  attributes  and  prepares 
expanded/modified  versions  of  the  DoD  Enterprise  Data  Model  for  review  and  approval. 

j  Maintains  an  audit  trail  of  all  entities  and  attributes  reviewed  and 
integrated  into  the  DoD  Enterprise  Data  Model. 

k.  Publishes  the  DoD  Enterprise  Data  Model  quarterly. 

l.  Implements,  maintains,  and  provides  training  on  automated  tools 
available  to  support  the  DoD  Enterprise  Model  review,  integration,  and  maintenance. 

m.  Supports  the  DoD  DAd,  as  needed,  with  other  activities  associated  with 
the  DoD  Enterprise  Data  Model  development,  approval,  and  maintenance  process. 

6.  Subject  Matter  Expert  (SME) 

a.  Brings  detailed  knowledge  of  data  details,  usage  in  AISs,  and  reporting 
requirements  to  collaborative  sessions  and  functional  reviews. 

b.  Supports  developers  and  reviewers  of  functional  area  data  models  with 
functional  guidance  and  assistance  for  issue  resolution. 
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c  Supports  integration  of  functional  area  data  models  into  functional  area 
data  architectures  and  into  the  DoD  Enterprise  Data  Model,  as  needed. 


7.  Functional  Area  Program  Managers  (FAPM) 

a.  Implements  Defense  IM  program  within  their  functional  activity. 


b.  Coordinates  functional  activity  issues  with  OSD  PSAs,  the  Chairman, 
Joint  Chiefs  of  Staff,  FDAds,  and  other  SMEs. 


c  Assists  FDAds  with  development,  reconciliation,  and  maintenance  of 
functional  area  activity  a  d  data  models.  This  includes  validating  that  data  requirements  are 
correctly  represented  for  the  functional  activities  they  represent. 


d.  Provides  technical  and  functional  expertise  to  FDAds  during  review  of 
proposed  functional  area  data  models  and  standard  data  elements. 


e.  Requires  development  of  candidate  standard  data  elements  to  support 
information  system  and  application  software  program  development. 


f  Plans  for  and  manages  implementation  of  process,  and  data  and 
information  system  standards  and  changes  approved  as  par.  of  functional  area  model 
standards  maintenance. 


8. 


Office  nf  the.  Secretary  oLDefenseJPrinciEa L^taffjissistMtiQSDm) 


a  Designates  an  FDAd  in  each  functional  area  for  which  they  are 
responsible.  OSD  PSAs  can  designate  themselves  as  the  FDAd  for  any  of  the.r  functional 

areas. 


b  Works  with  proposal  package  data  stewards,  FDAds,  and  other  SMEs  as 
needed  to  ensure  accurate  functional  representation  in  all  data  models  being  proposed 
extend  the  DoD  Enterprise  Data  Model. 


c  Reviews  and  approves  all  functional  area  data  models  prior  to 
submission  for  formal  review  and  integration  into  the  DoD  Enterprise  Data  Model. 


d.  Resolves  all  proposal  package/collaborative  session  issues  that  adversely 
affect  readiness  or  inability  to  comply  with  the  law. 


e  Supports  the  DASD(IM)  in  resolving  issues  that  cannot  be  resolved  by 
FDAds,  CDAdsj  the  DoD  DAd,  and  other  SMEs  during  the  formal  review  process. 
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Deputy  Assistant  Secretary  of  Defense  for  Information  Management 


9. 

(DASDOM)) 


a.  Resolves  technical  and/or  functional  data  model  issues  that  still  exist 
after  the  formal  cross-functional  review  and  that  can  not  be  resolved  by  the  DoD  DAd, 
FDAds,  CD  Ads,  and  other  SMEs. 

b.  Forwards  issues  that  cannot  be  resolved  by  the  DASD(IM),  the  DoD 
DAd,  FDAds,  CDAds,  and  other  SMEs  with  recommended  actions  to  the  ASD(C3I)  for  final 
disposition. 


c.  Distributes  information  on  issues  resolved  by  the  DASD(IM)  and/or  the 
ASD(C3I)  to  the  DoD  DAd  and  OSD  PSAs. 

10.  Assistant  Secretary  of  Defense  for  Command.  Control.  Communications  and 
Intelligence  tASDfC3Dl 

a.  Issues  policy  and  guidance  on  DoD  Data  Administration. 

b.  Designates  a  DoD  DAd. 

c.  Resolves  issues  that  can  not  be  resolved  during  rapid  data 
standardization  collaborative  sessions  by  the  DoD  DAd,  FDAds,  CDAds  and  other  SMEs. 

d.  Resolves  data  model  issues  that  remain  after  the  cross-functional  review 
and  that  cannot  be  resolved  by  the  DASD(IM),  DoD  DAd,  FDAds,  CDAds,  and  other  SMEs. 
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CHAPTER  3 


DATA  MODELING  CONCEPTS 


A.  INTRODUCTION 

This  chapter  presents  concepts  that  are  fundamental  to  data  modeling.  The  information 
provides  a  basis  for  understanding  the  development,  approval,  and  maintenance  procedures  for 
the  DoD  Enterprise  Data  Model. 

B.  DATA  MODEL  CONCEPTS 

1.  A  data  model  is  the  graphical  and  textual  representation  of  data  a  business  needs 
to  accomplish  its  mission.  It  is  a  representation  of  data  objects  that  can  be  shared  and  reused 
across  application  systems,  organizational  boundaries,  and  different  functional  areas. 


2.  The  DoD  Enterprise  Data  Model  is  developed  and  continuously  extended  based 
on  reviews  of  data  models  developed  to  document  data  requirements  across  DoD  functional  areas. 
As  shown  in  Figure  3-1,  multiple  views  of  the  DoD  Enterprise  Data  Model  provide  an 
architectural  structure  from  which  standard  data  elements  and  data  structures  originate.  The  DoD 
Enterprise  Data  Model,  together  with  the  DoD  Enterprise  Activity  Model,  comprise  the  DoD 
Enterprise  Model.  The  relationship  between  the  BPR  process  and  the  DoD  Data  Administration 
process  is  discussed  in  Appendix  B. 

3.  Models 


a.  Provide  information  about  the  interests  of  an  enterprise. 

b.  Facilitate  improvements  in  strategies,  tactics,  and  operations. 

c.  Provide  a  basis  for  information  systems  database  design. 

d.  Provide  a  basis  for  accuracy  and  integrity  of  information. 

e.  Facilitate  understanding  of  data  that  leads  to  the  identification  of  data  sharing 

possibilities. 

f.  Help  reduce  redundant  data  entry  and  unintentional  replication  of  data. 
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Standard  Data  Elements 
Standard  Data  Structures 

Figure  3-1:  Context  for  Standardizing  DoD  Data  for 
Improved  Data  Exchange  and  System  Interoperability 
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4.  Data  models  and  schema(s)  are  used  to  depict  information  needs  or  data  requirements 
from  a  number  of  views.  These  views  are  typically  mapped  to  one  another  to  support  the 
integration  of  strategic  planning,  business  area  planning,  system  requirements  identification,  and 
AIS  design,  development,  and  maintenance.  Two  types  of  data  models  and  three  types  of 
schemas  are  used  to  support  the  information  management  integration  architecture. 

a.  Data  Models 


Two  types  of  data  models  are  used  to  support  enterprise,  mission,  and 
functional  area  integration.  The  models  are  descriptive  representations  of  the  data  requirements 
that  support  strategic  or  functional  area  business  needs. 

(1)  Strategic  Data  Models 

High-level  models  of  data  requirements  that  support  the  information 
needs  across  the  corporate  enterprise.  A  strategic  data  model  is  typically  used  for  strategic  data 
planning  and  policy  purposes.  The  DoD  Enterprise  Data  Model  is  an  example  of  a  strategic  data 
model.  It  supports  DoD  enterprise  and  mission-level  integration. 

(2)  Functional  Area  Data  Models 

Business  area  models  of  data  requirements  that  support  specific 
information  needs  within  or  between  the  major  functional  areas  of  a  business.  A  functional  area 
data  model  is  typically  used  for  business  area  analysis  to  support  functional  area  integration. 

b.  Schemas 


Three  types  of  schemas  (conceptual,  internal,  and  external)  are  used  to 
support  application,  local,  and  personal-level  integration.  Figure  3-2  graphically  presents  an 
overview  of  these  three  schema  types.  The  schema  views  of  data  requirements  include  (reference 

(h)): 


(1)  Conceptual  Schema 

The  conceptual  schema  represents  the  "logical"  view  or  data 
administrator's  view  of  the  data  requirement.  This  view  is  represented  as  a  data  model,  using  a 
structured  technique  such  as  Integrated  Definition  for  Information  Modeling  (IDEF1X),  to  specify 
what  information  is  stored  about  objects  of  interest  to  the  functional  area.  This  view  is  a  single 
integrated  definition  of  the  data  that  is  unbiased  toward  any  single  application  of  data  and  is 
independent  of  how  the  data  are  physically  stored  or  accessed.  An  attributed,  normalized  data 
model  is  also  referred  to  as  a  conceptual  schema.  The  conceptual  schema  is  used  for  data 
standardization  and  database  design.  It  is  also  used  to  support  application  integration. 
Conceptual  Scheme  provides  a  consistent  definition  of  the  meanings  and  interrelationships  of  the 
data  used  to  integrate,  share,  and  manage  the  integrity  of  data  within  and  across  applications. 
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Conceptual  Schema 
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Figure  3-2:  Three  Schema  Architecture 


(2)  Internal  Schema 


The  internal  schema  represents  the  "physical"  view  or  database 
administrator's  view  of  the  data  requirement.  This  view,  also  known  as  a  physical  database 
design,  is  described  by  a  data  definition  language  (DDL)  and  physical  storage  methods  used  to 
implement  the  data  requirements  described  under  a  conceptual  schema.  The  denormalization  of 
conceptual  schema  data  requirements  may  occur  in  connection  with  system  performance  and 
technological  constraints.  Any  denormalization  shall  be  coordinated  with  the  manager  of  the 
conceptual  schema  (i.e.,  Data  Administrator).  The  internal  schema  is  also  referred  to  as  a 
physical  data  model.  The  design  and  development  of  internal  schema  supports  integration  at  the 
application  and  local  levels. 

(3)  External  Schema 

The  external  schema  represents  the  "user"  view  or  application  view 
of  the  data  requirement.  This  view  is  represented  by  reports,  transactions,  and  screens  that  are 
designed  to  support  the  individual  worker  in  the  performance  of  tasks  or  activities.  The  external 
schema  is  referred  to  as  the  end-user  view(s).  The  design  and  development  of  external  schema(s) 
is  equivalent  to  the  design  and  development  of  the  human-computer  interface  (HCI)  for  the  AIS 
and  supports  integration  at  the  local  and  personal  levels  of  the  information  management 
integration  architecture. 

5.  IDEF1X  has  been  established  as  the  DoD  standard  technique  for  data  model 
presentation  and  integration.  DoD  rules,  syntax,  and  techniques  for  IDEF1X  are  presented  in  the 
National  Institute  of  Standards  (NIST)  publication  FIPS  PUB  184  entitled  "Specifications  for 
Integration  Definition  for  Information  Modeling  (IDEF1X),"  (reference  (i)).  Other  modeling 
techniques  exist  and  are  being  used  within  DoD.  Models  using  non-IDEFIX  techniques  will  be 
accepted  by  DoD  for  review  and  integrated  into  the  DoD  Enterprise  Data  Model  under  certain 
circumstances.  These  circumstances  will  be  evaluated  on  a  case-by-case  basis  between  the 
functional  area  submitting  the  model,  the  DoD  DAd,  and  representatives  from  DAPMO  who  are 
responsible  for  integrating  proposed  model  components  into  the  DoD  Enterprise  Data  Model. 

6.  The  basic  components  of  a  data  model  are  entities,  attributes,  and  relationships, 
a.  Entity 

An  object  about  which  the  business  wishes  to  collect  information;  a  person, 
place,  thing,  event,  or  concept  of  importance  to  the  enterprise  that  is  singular,  exclusive,  and 
identifiable.  An  entity  is  also  known  as  an  Entity  Type  or  Entity  Class. 

(1)  The  entity  occurrence  is  an  instance  of  the  entity.  Each  entity 
instance  shall  be  distinguishable  from  all  other  instances  of  the  same  entity. 
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(2)  The  entity  relationship  diagram  (ERD),  depicted  in  Figure  3-3,  is 
a  graphic  representation  of  a  data  model.  The  basic  icons  or  symbols  are  a  rectangle  containing 
a  name  for  an  entity  and  a  line  with  cardinality  depicting  a  relationship.  An  ERD  is  supported 
by  a  narrative  description  of  the  object  occurrences  represented  by  icons.  Figure  3-3  uses 
IDEF1X  terms  and  techniques. 


ENTITY  A  ENTITY  B 


\ 

relationship 

— m 

j 

Figure  3-3:  Entity  Relationship  Diagram 


(3)  There  are  two  basic  categories  of  entities:  independent  and 

dependent. 

(a)  Independent  Entity.  An  object  of  interest  to  the  business  that 
does  not  depend  on  any  other  entity  for  its  existence.  Each  entity  occurrence  of  an  independent 
entity  can  be  identified  using  primary  key  attributes  that  characterize  the  object  without  referring 
to  foreign  keys  migrated  from  any  other  entity.  Also  known  as  fundamental,  principal,  primary, 
independent  entity  class,  and  supertype. 

(b)  Dependent  Entity.  An  entity  that  depends  on  the  existence 
of  one  or  more  other  entities  for  its  identification.  The  entities  on  which  it  depends  can  be  either 
independent  or  dependent.  The  primary  key  for  a  dependent  entity  contains  foreign  keys 
contributed  by  the  entities  on  which  it  depends.  There  are  three  basic  types  of  dependent  entities: 
category,  attributive,  and  associative. 
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1  Category  Entity.  A  subset  of  the  instances  of  a  single¬ 
parent  entity  (referred  to  as  a  generalization  entity,  or  generic  parent).  Figure  3-4  shows  two 
category  entities  (i.e.,  MILITARY  MEMBER  and  CIVILIAN  EMPLOYEE)  for  the  parent  entity 
named  PERSON.  The  category  entity  appropriate  for  a  specific  instance  of  the  parent  entity  is 
determined  by  a  category  discriminator  attribute  in  the  parent  entity  (e.g.,  Person  Service  Type 
Code  in  Figure  3-4).  Each  category  entity  inherits  common  attributes  and/or  relationships  from 
the  parent,  including  its  primary  keys  (which  become  foreign  keys  in  the  category  entity).  The 
category  entity  contains  additional  attributes  and/or  relationships  that  are  related  to  the  parent  but 
that  are  distinct  from  other  related  subsets.  It  also  contains  some  attributes  and/or  relationship(s) 
that  apply  only  to  instances  of  the  subset  and  not  to  all  instances  of  the  parent.  Category  entities 
are  used  to  migrate  a  data  model  to  fourth-normal  form,  because  they  eliminate  null  attribute 
values  in  the  parent  entity.  A  category  entity  is  known  as  subentity  or  secondary  entity. 


2  Attributive  Entity.  An  entity  that  accommodates 
repeating  attributes  for  the  parent  entity.  Figure  3-5  is  an  example  of  an  attributive  entity  named 
PERSON  LANGUAGE  that  documents  the  multiple  languages  a  person  might  speak  and/or  write. 
Additional  attributes  (e.g.,  Language  Identifier)  are  appended  to  the  key  structure  of  the 
attributive  entity  that  do  not  appear  in  the  key  structure  for  the  parent  entity.  These  additional 
key  attributes  uniquely  distinguish  between  multiple  values  for  the  repeating  attributes.  An 
attributive  entity  is  a  dependent  entity  with  exactly  one  identifying  parent.  Attributive  entities 
are  created  to  support  the  first  rule  of  normalization:  eliminating  repeating  attributes  from  the 
parent  entity.  An  attributive  entity  is  also  known  as  a  characteristic  entity. 


PERSON 


Figure  3-5:  Example  Attributive  Entity 
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3  Associative  Entity.  An  entity  that  inherits  its  primary 
key  from  two  or  more  other  entities  and  records  multiple  associations  (relationships)  between 
those  entities.  The  primary  use  of  associative  entities  is  to  reconcile  nonspecific  (many-to-many) 
relationships  between  two  or  more  entities.  An  associative  entity  has  no  unique  key  attributes; 
if  it  does,  it  becomes  an  attributive  entity.  Figure  3-6  is  an  example  of  an  associative  entity 
named  PERSON  SKILL  resolving  the  many-to-many  relationship  between  two  parent  entities 
named  PERSON  and  SKILL.  The  difference  between  an  associative  entity  and  an  attributive 
entity  is  the  number  of  identifying  relationships  to  the  parent.  An  attributive  entity  has  only  one 
identifying  relationship  and  an  associative  entity  has  more  than  one.  An  associative  entity  is  also 
known  as  an  intersecting  entity. 


Associative  Entity 


Figure  3-6:  Example  Associative  Entity 


(4)  Each  entity  in  a  data  model  is  assigned  a  functional  data  steward.  The 
data  steward  is  the  FDAd  of  the  functional  area  that  manages  the  development,  approval,  and 
creation  of  the  data  representing  the  entity  and  all  or  part  of  its  attributes.  The  data  steward 
ensures  that  the  data  are  used  to  satisfy  information  requirements  throughout  DoD  and  documents 
the  appropriate  business  requirements.  The  data  steward  is  determined  by  identifying  the 
functional  area  that  manages  the  process  that  creates  the  data.  The  assignment,  responsibilities, 
and  issue  resolution  associated  with  assignment  of  functional  data  stewards  are  discussed  in 
greater  detail  in  Chapter  2. 
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b.  Attribute 


A  property  or  characteristic  of  an  entity  or  entity  class.  For  example,  COLOR, 
WEIGHT,  GENDER.  All  attributes  describe  an  entity.  One  or  more  of  these  attributes  are  used 
to  uniquely  identify  an  instance  of  an  entity.  Only  logical  attributes  should  be  represented  in  a 
logical  data  model.  Logical  attributes  are  atomic  characteristics  of  an  entity.  There  are  two  types 
of  attributes:  key  and  nonkey. 

(1)  Kev  Attribute.  One  or  more  attributes  that  may  be  used  to  uniquely 
identify  an  instance  of  an  entity  or  entity  class.  There  are  three  types  of  key  attributes:  primary 
keys,  alternate  keys,  and  foreign  keys. 

(a)  Primary  Kev.  An  attribute  or  group  of  attributes  chosen  to  uniquely 
identify  an  entity.  In  Figure  3-6,  for  example,  person  identifier  is  the  primary  key  for  the  entity 
named  PERSON.  In  IDEF1X,  attributes  are  designated  as  primary  keys  by  placing  them  in  the 
primary  key  area  of  the  entity  box  (i.e.,  above  the  horizontal  line).  Primary  keys  are  never  null. 
Each  entity  or  entity  class  has  one  and  only  one  primary  key.  A  primary  key  is  migrated  through 
relationships  to  become  a  foreign  key  in  child  or  dependent  entities.  Primary  keys  are  also 
known  as  determinants  or  identifiers.  Rules  for  primary  keys  are  described  in  Chapter  6. 

(b)  Alternate  Kev.  Attribute(s)  that  can  be  used  to  uniquely  identify 
an  entity  instance,  but  is  not  designated  as  part  of  the  entity  primary  key.  In  Figure  3-6,  for 
example,  social  security  number  is  designated  as  an  alternate  key  by  the  letters  "AK1"  in 
parenthesis  to  the  right  of  the  attribute  name.  Numbers  (e.g.,  AK1,  AK2,  AK3)  are  used  to 
distinguish  among  multiple  alternate  keys  specified  for  a  single  entity. 

(c)  Foreign  Kev.  An  attribute  or  group  of  attributes  in  an  entity  that 
are  inherited  from  another  entity  through  a  relationship.  Foreign  keys  show  relationships  between 
child  or  dependent  entities  and  parent  entities.  The  foreign  key  may  or  may  not  become  part  of 
the  primary  key  of  the  child  or  dependent  entity.  In  Figure  3-6,  the  attributes  person  identifier 
and  skill  identifier  are  foreign  keys  for  the  associative  entity  named  PERSON  SKILL.  In 
IDEF1X,  foreign  keys  are  designated  by  placing  the  letters  "FK"  in  parenthesis  to  the  right  of  the 

attribute  names. 

(2)  Nonkev  Attribute.  Attribute  or  group  of  attributes  that  describe  an  entity 
but  that  cannot  be  used  to  uniquely  identify  the  entity  or  relate  the  entity  to  another  entity.  In 
Figure  3-6,  the  attributes  person  name  and  person  birth  date  are  examples  of  nonkey  attributes 
for  the  entity  named  PERSON. 

(3)  Derived  Attribute.  Characteristic  representing  the  results  of 
computational  operations  performed  on  other  attributes.  Derived  attributes  are  inherently 
redundant  to  both  primitive  sources  from  which  they  are  assimilated  and  to  other  derived 
attributes.  Furthermore,  the  derived  attributes  communicate  decisions  about  procedures  and 
applications  that  should  be  removed  from  logical  models.  Derived  attributes  should  be 
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represented  in  a  logical  functional  data  model  when  they  support  accounting,  auditing,  legal 
policy,  or  business  rule  enforcement.  Derived  attributes  may  be  included  in  data  models  for 
decision  support  applications  that  document  specifications  for  external  views  of  the  logical 
conceptual  model. 

(4)  Composite  Attributes.  Characteristic  that  describes  multiple  concepts. 
When  an  attribute  is  formulated  to  describe  multiple  concepts,  its  definition  and  meaning  can 
easily  partially  overlap  with  the  definition  of  another  attribute.  This  redundancy  sets  the  stage 
for  data  inconsistencies.  An  attribute  should  be  designed  to  communicate  a  single  concept  when 
represented  in  a  logical  data  model.  However,  many  composite  legacy  elements  are 
institutionalized  and  well  understood  by  the  functional  community.  The  decision  to  redesign  an 
institutionalized  composite  legacy  element  should  be  based  on  a  consideration  of  the  impacts  this 
effort  will  have  on  improving  the  Department's  ability  to  share  data.  If  little  or  no  improvement 
is  foreseen  (i.e.,  the  risk  for  poor  data  quality  and  poor  ability  to  share  data  is  low  for  the 
existing  legacy  element),  then  consider  partial  redesign  or  acceptance  of  the  legacy  element  as 
it  stands. 


(5)  Metadata.  Information  describing  the  characteristics  of  data;  data  or 
information  about  data;  or  descriptive  information  about  an  organization's  data,  data  activities, 
systems,  and  holdings.  NIST  Special  Publication  500-173  (reference  (h)). 

c.  Relationship 

A  relationship  is  a  meaningful  association  between  two  entities.  The  basic 
components  of  a  relationship  are:  cardinality,  relationship  name,  and  business  rules. 

(1)  Cardinality.  A  statement  of  the  number  of  entity  instances  that  may  or 
shall  participate  at  each  end  of  a  relationship.  Cardinality  is  the  combination  of  degree  and 
nature. 


(a)  Degree.  The  number  of  instances  from  one  entity  occurrence  to 
another  entity  occurrence.  It  expresses  the  number  of  permitted  associations  between  entity 
occurrences.  Expressions  include  one  (1),  many  (N  or  M),  or  predetermined  number  (e.g.,  2). 
For  example,  Equipment  Item  SUPPORTS  many  Weapon  System(s);  Weapon  System  IS 
SUPPORTED  BY  many  Equipment  Item(s).  Entity  relationships  are  also  described  as  one-to-one, 
one-to-many,  or  many-to-many.  Specific  numbers  (two  through  infinity)  are  optional. 

(b)  Nature.  Expresses  whether  the  association  between  an  entity 
occurrence  and  another  entity  occurrence  is  mandatory  or  optional;  also  referred  to  as  obligatory 
or  nonobligatory.  Expressions  include  one  (1)  for  mandatory  and  zero  (0)  for  optional.  For 
example,  Equipment  Item  SUPPORTS  zero  or  many  Weapon  System(s);  Weapon  System  IS 
SUPPORTED  BY  one  or  many  Equipment  Item(s). 

(2)  Relationship  Name.  Always  a  verb  or  verb  phrase,  the  label  given  to 
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a  relationship.  The  name  of  the  relationship  reflects  the  activity  or  function  that  takes  place 
between  two  entities.  When  read  in  sequence  (entity-relationship-entity),  a  statement  is  made 
about  the  organization  operations.  Multiple  relationships  between  the  same  entities  are  best 
described  by  roles  given  to  an  entity  or  reasons  given  to  an  association.  Significant  relationships 
include  parent  entities  upon  which  one  or  more  other  entities  depend.  Attributive  and  category 
entities  will  always  be  associated  with  at  least  one  independent  entity;  and  an  associative  entity 
will  have  a  minimum  of  two  related  parent  entities.  A  relationship  name  is  also  known  as  a 

relationship  label. 

(3)  Rnsiness  Rules.  A  statement  or  fact  that  defines  the  constraints  and 
relationships  between  attributes.  This  statement  describes  the  constraints  the  business 
environment  imposes  on  how  two  entities  are  related.  Each  business  rule  statement  should  be 
constructed  so  that  the  parent  entity  name  is  the  subject,  the  relationship  name  is  the  verb  phrase, 
and  the  child  entity  name  is  the  object. 

EXAMPLES: 

Every  PROJECT  is  always  supported  by  one  or  many  ACCOUNT(s) 

A  MAINTENANCE-REQUEST  may  generate  zero,  one,  or  many  MAINTENANCE  TASK(s) 

d.  In  addition  to  the  basic  components  of  the  data  model,  there  are  various 
associations  to  other  models,  such  as  activity  models  and  organizational  and  geographic 
structures,  which  provide  a  comprehensive  view  of  the  architecture  of  the  enterprise.  A  broader 
explanation  of  the  relationship  between  activity  models  and  data  models  is  provided  in  Appendix 

B. 

C.  PRTMF,  WORD  {ENTITY}  STANDARDIZATION  PHASES 

The  procedures  described  in  this  manual  relate  to  those  in  DoD  8320.1-M-l  (reference  (b)). 
As  a  model  proposal  moves  through  the  model  review  process,  its  entities  and  attributes  move 
through  the  data  element  standardization  process  as  prime  words  and  data  elements.  The 
following  summarizes  the  standardization  phases  for  a  prime  word  (entity)  and  how  it  is  related 
to  the  model  review  process: 

1.  Developmental.  A  prime  word  (entity)  is  considered  developmental  before  release 

by  the  originator(s)  for  consideration  as  an  extension  of  the  DoD  Enterprise  Data  Model.  A 
developmental  prime  word  is  coordinated  for  preliminary/informal  review  to  resolve  functional 
and  technical  issues  based  on  procedures  described  in  Chapter  5. 

2.  Candidate.  A  prime  word  (entity),  having  met  preliminary/informal  review 
requirements,  is  changed  to  a  Candidate  status  when  its  proposal  package  is  submitted  into  the 
formal  approval  process  by  the  FDAd,  designated  as  the  proposal  package  functional  data 
steward.  As  a  result  of  the  cross-functional  review,  conducted  during  the  formal  approval 
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process,  the  decision  will  be  made  to  approve,  disapprove,  or  submit  the  candidate  prime  word 
(entity)  for  issue  resolution. 

3.  Approved.  A  prime  word  (entity)  is  approved  when  it  has  been  coordinated 
through  the  formal  functional  and  technical  review  process  and  has  been  approved  for  use.  An 
approved  prime  word  is  considered  an  extension  to  the  DoD  Enterprise  Data  Model. 

4.  Disapproved.  A  candidate  prime  word  (entity)  is  changed  to  disapproved  if  it  is 
determined  to  be  technically  or  functionally  noncompliant  during  the  formal  review  process. 

5.  Modified.  When  an  approved  prime  word  (entity)  in  the  DoD  Enterprise  Data 
Model  is  being  considered  for  change,  a  proposal  package  describing  the  modified  prime  word 
is  submitted.  The  proposal  shall  undergo  a  preliminary  and/or  informal  review,  whereby  it  shall 
satisfy  functional  and  technical  requirements.  After  the  informal  review,  the  modified  prime  word 
undergoes  the  same  formal  review  process  as  a  new  candidate.  If  the  modified  proposal  is 
approved,  the  new  version  of  the  prime  word  becomes  part  of  the  DoD  Enterprise  Data  Model. 
A  history  of  modifications  made  to  a  prime  word  is  tracked  over  time  through  version  numbers 
assigned  to  subsequent  approved  versions  of  the  prime  word  in  the  DDRS. 

6.  Archived.  When  an  approved  prime  word  (entity)  in  the  DoD  Enterprise  Data 
Model  is  no  longer  considered  a  DoD  information  requirement,  a  proposal  is  submitted  that 
identifies  the  prime  word  as  a  candidate  for  archive.  The  archive  proposal  undergoes  the  same 
formal  review  process  as  a  new  candidate.  If  approved,  the  status  of  the  latest  version  of  the 
prime  word  (entity)  is  changed  to  Archived. 

7.  Reinstated.  An  archived  prime  word  (entity)  is  changed  to  a  reinstated  status 
when  the  archived  entity  is  being  considered  for  reinstatement  without  modification  to  the  DoD 
Enterprise  Data  Model.  A  reinstated  prime  word  (entity)  undergoes  the  same  formal  review 
process  as  the  candidate.  An  archived  entity  being  considered  for  reinstatement  with  modification 
is  processed  as  a  new  developmental  prime  word. 
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CHAPTER  4 


DoD  ENTERPRISE  DATA  MODEL  DEVELOPMENT  AND  APPROVAL  PROCEDURES 


A.  INTRODUCTION 

1.  This  chapter  describes  procedures  for  developing  and  approving  extensions  to  the 
DoD  Enterprise  Data  Model.  New  versions  of  the  DoD  Enterprise  Data  Model,  resulting 
from  these  procedures,  will  be  used  to  produce  standard  data.  Specifically,  approved  entities 
will  become  standard  prime  words  with  functional  data  stewards.  As  entities  are  approved, 
their  attributes  will  become  candidate  data  elements  for  approval  in  accordance  with  DoD 
8320.1-M-l  (reference  (b)). 

2.  Proposal  packages  shall  be  prepared  in  accordance  with  proposal  package 
preparation  guidelines  provided  in  Chapter  5,  technical  and  functional  requirements  described 
in  Chapter  6,  and  DoD  8320.1-M-l  (reference  (b)). 

3.  There  are  two  alternative  paths  for  preparing  and  submitting  functional  data  model 
proposal  packages  to  extend  and/or  modify  the  DoD  Enterprise  Data  Model.  The  first  is 
through  the  use  of  rapid  data  standardization  collaborative  sessions  introduced  in  the  Rapid 
Data  Standardization  Guidance  document  (reference  (j)).  The  second  is  through  FDAd, 
CDAd  and  functional  data  steward  coordinated  reviews.  Both  of  these  alternatives  produce  a 
data  model  proposal  package(s)  for  submission  to  the  formal  8320.1-M-x  review  process. 

4.  The  rapid  data  standardization  collaborative  sessions  alternative  is  shown  in  Figure 
4-1.  The  goal  of  these  sessions  is  to  minimize  the  amount  of  time  required  to  prepare  a 
proposal  package  for  submission  to  the  formal  review  process.  This  is  done  by  bringing 
functional  stakeholders  and  SMEs  into  one  place  for  rapid  proposal  preparation,  review,  and 
issue  resolution.  This  process  consists  of  the  following  three  basic  steps: 

a.  Identify  and  Select  Projects.  Collaborative  session  candidate  projects 
are  nominated  by  FDAds  and  CD  Ads  based  on  designated  migration  systems.  Projects  are 
reviewed  and  selected  by  the  DoD  DAd.  Each  project  selected  will  have  a  migration  system 
or  application  topic  (e.g.,  GCCS  /  GSORTS)  and  a  data  topic  (a  DoD  Data  Model  subject 
area,  e.g.,  Location). 

b.  Plan  and  Hold  Collaborative  Sessions.  Collaborative  sessions  are 
planned  by  FDAds,  the  DoD  DAd,  and  CDAds;  managed  by  the  DAPMO  and  an  outside 
facilitator;  and  attended  by  FDAds,  CDAds,  DAPMO  representative(s),  Cfdads,  and  other 
SME's.  The  output  of  rapid  data  standardization  sessions  is  candidate  data  in  the  form  of 
data  model  proposal  packages  ready  for  formal  review.  These  proposal  packages  contain 
functionally  and  technically  reviewed  data  models  with  entities  (prime  words)  and  attributes 
(data  elements)  and  their  supporting  metadata. 
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Standardization  Process 


-2 


c. 


Conduct  a  Formal  Review 


(1)  During  the  formal  review  process,  the  DoD  DAd,  supported  by 
representatives  from  DAPMO,  will  validate  the  technical  review  conducted  during  the  rapid 
data  standardization  collaborative  sessions.  They  will  create  a  new  proposed  view  of  the  DoD 
Enterprise  Data  Model  and  coordinate  the  cross-functional  review. 

(2)  If  changes  are  proposed  to  any  approved  entities  or  attributes,  users 
of  those  entities  or  attributes  that  are  registered  in  the  DDRS  will  be  contacted  and  invited  to 
contribute  to  the  cross-functional  review. 

(3)  After  evaluating  the  results  of  the  cross-functional  review  with  the 
FDAd  designated  as  the  proposal  package  functional  data  steward,  the  DoD  DAd  will  decide 
to  approve  or  disapprove  the  proposal  package,  or  forward  issues  for  resolution  to  the 
DASD(IM). 

5.  The  FDAd,  CD  Ad,  and  functional  data  steward  coordinated  reviews  alternative, 
depicted  in  Figure  4-2,  consist  of  three  basic  steps:  prepare  a  proposal  package  and  conduct  a 
preliminary  review,  conduct  an  informal  review,  and  conduct  a  formal  review. 

a.  Prepare  a  Proposal  Package  and  Conduct  a  Preliminary  Review 

(1)  A  proposal  package,  consisting  of  a  proposed  model/model  subset, 
is  required  to  extend  or  update  the  DoD  Enterprise  Data  Model.  The  proposal  package  is 
submitted  by  the  originator  (any  person  within  DoD  or  representing  a  DoD  organization)  to 
the  originator's  respective  FDAd  or  CDAd  to  begin  the  data  model  review  process. 

(2)  Upon  receipt  of  the  proposal  package,  the  FDAd  or  CDAd  conducts 
a  preliminary  review.  The  preliminary  review  is  an  iterative  process  between  the  originator 
and  the  FDAd  or  CDAd  to  ensure  the  quality  of  the  proposal  package  before  it  is  submitted  to 
the  FDAd,  designated  as  the  proposal  package  functional  data  steward,  for  informal  review. 
The  quality  of  a  proposal  package  will  be  measured  in  terms  of  functional  and  technical 
compliance. 


(3)  The  preliminary  review  includes  selecting  functional  data  stewards 
for  the  overall  proposal,  and  each  proposed  entity  and  attribute.  If  functional  data  stewardship 
assignments  cannot  be  made  based  on  the  functional  content  of  the  proposal  package,  an 
individual  entity,  or  attribute,  then  the  DoD  DAd  should  be  consulted.  The  DoD  DAd  will 
work  with  the  FDAd  or  CDAd  to  select  and  assign  appropriate  proposal,  entity,  and/or 
attribute  functional  data  stewards.  Functional  data  steward  responsibilities  are  discussed  in 
Chapter  2. 
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Preliminary  Review  Informal  Review  Formal  Review 


b.  Conduct  an  Informal  Review 


(1)  The  informal  review  is  an  iterative  process  between  the  FDAd 
designated  as  the  proposal  package  functional  data  steward,  entity  functional  data  stewards, 
attribute  functional  data  stewards,  OSD  PSAs,  CDAds,  and  other  SMEs. 

(2)  During  this  iterative  process,  the  proposal  package  functional  data 
steward  coordinates,  schedules,  and  prioritizes  model/model  subset  reviews,  validates 
functional  data  stewardship  assignments  and  ensures  that  functional  and  technical  reviews  are 
conducted  consistently.  If  needed,  the  DoD  DAd  will  also  be  consulted  during  this  review  to 
resolve  functional  data  stewardship  assignment  and  technical  issues. 

(3)  Upon  completing  the  informal  review,  the  proposed  model/model 
subset  is  submitted  for  formal  review  by  the  proposal  package  functional  data  steward. 

c.  Conduct  a  Formal  Review 


(1)  During  the  formal  review  process,  the  DoD  DAd,  supported  by 
representatives  from  the  DAPMO,  will  perform  a  technical  review  on  the  proposal  package, 
create  a  new  proposed  view  of  the  DoD  Enterprise  Data  Model,  and  coordinate  the  cross¬ 
functional  review. 


(2)  If  changes  are  proposed  to  any  approved  entities  or  attributes,  users 
of  the  those  entities  or  attributes  that  are  registered  in  the  DDRS  will  be  contacted  and  invited 
to  contribute  to  the  cross-functional  review. 

(3)  After  evaluating  the  results  of  the  cross-functional  review  with  the 
FDAd,  designated  as  the  proposal  package  functional  data  steward,  the  DoD  DAd  will  decide 
to  approve  or  disapprove  the  proposal  package  or  forward  issues  for  resolution  to  the 
DASD(IM). 

6.  Store/Maintain  DoD  Data  Products 


a.  Prime  words;  standard  data  elements  developed  from  attributes;  and 
associated  required  metadata  produced  by  the  rapid  data  standardization  and  FDAd,  CDAd, 
and  functional  data  steward  review  processes  will  be  stored,  reviewed,  and  maintained  in  the 
DDRS.  Entities  (prime  words)  and  attributes  (data  elements)  should  be  entered  into  the 
system  as  early  as  possible  to  support  automated  review,  access,  and  comment.  Procedures 
for  maintaining  DoD  Enterprise  Data  Model  entities  (prime  words)  are  discussed  in  Chapter  7 
Procedures  for  maintaining  standard  data  elements  are  discussed  in  DoD  8320.1-M-l 
(reference  (b)).  Versions  of  each  prime  word  and  standard  data  element  will  be  recorded  in 
the  DDRS  for  reference  and  archive  purposes.  Contact  the  DAPMO  to  obtain  access  to  and 
documentation  for  the  DDRS. 
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b.  Data  models  will  be  stored  in  the  DoD  Interim  IDEF  Repository.  This 
includes  both  the  DoD  Enterprise  Data  Model  and  individual  functional  area  models  used  to 
expand  the  DoD  Enterprise  Data  Model.  Contact  the  Center  for  Information  Management 
(CIM)  Center  for  Functional  Process  Improvement  Expertise  to  obtain  access  to  and 
documentation  for  the  DoD  Interim  IDEF  Repository. 

B.  RAPID  DATA  STANDARDIZATION  COLLABORATIVE  SESSIONS 

1 .  The  goal  of  these  sessions  is  to  minimize  the  amount  of  time  required  to  prepare  a 
proposal  package  for  submission  to  the  formal  review  process.  This  is  done  by  bringing 
functional  stakeholders  and  SMEs  together  for  rapid  proposal  preparation,  review,  and  issue 
resolution.  Note  that  this  process  is  one  technique  for  completing  the  package  review  and 
approval  process  and  is  not  required. 

This  process  consists  of  three  basic  steps:  identify  and  select  projects,  plan  and  hold 
collaborative  sessions,  and  conduct  formal  reviews. 

2.  Identify  and  Select  Projects 

a.  Candidate  projects  are  nominated  by  FDAds  and  CDAds  based  on 
important  migration  system,  functional  and/or  cross-functional  standard  data,  and/or  BPR 
requirements. 

b.  Each  project  selected  will  have  a  migration  system  or  application  topic 
(e.g.,  GCCS/GS ORTS )  and  a  data  topic  (a  DoD  Data  Model  subject  area,  e.g.,  Location). 

c.  Each  project  selected  will  extend  a  subject  area  portion  of  the  DoD  Data 
Model  in  sufficient  detail  to  ensure  that  data  requirements  of  the  system/application  at  issue 
are  represented  and  can  be  standardized. 

d.  Candidate  projects  are  reviewed  and  selected  by  the  DoD  DAd  based  on 
project  scope,  duration,  functional  and  cross-functional  importance  to  DoD,  quality  and 
quantity  of  available  documentation,  expertise  of  participants,  and  return  on  investment  for 
the  Department. 

3.  Plan  and  Hold  Collaborative  Sessions 

a.  Collaborative  sessions  are  planned  by  FDAds,  the  DoD  DAd,  and 
CDAds.  Meetings  are  held  to  identify  what  information  exists,  prioritize  subfunctional  and 
interfacing  areas  to  be  addressed,  identify  and  prioritize  preparatory  tasks,  set  a  schedule,  and 
identify  who,  at  a  minimum,  needs  to  be  involved. 

b.  DAPMO  representatives  with  input  from  the  co-chairs  plan  the  facilities, 
sessions,  and  an  agenda  to  accommodate  and  facilitate  representative  participation. 
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c.  Projects  are  managed  by  the  DAPMO  and  facilitated  by  a  third  party. 

d.  Projects  are  controlled  by  stringent  time-lines  agreed  to  by  the  co-chairs 
and  implemented  by  the  DAPMO  and  the  facilitator. 

e.  Participants  will  provide  pertinent  documentation  10  days  before  the 
session  and  co-chairpersons  will  consolidate  the  information  and  provide  copies  to  the 
participants  before  each  session. 

f.  Participants  will  have  the  authority  to  represent  their  organizations  in 
situations  requiring  technical  and  functional  decisions. 

(1)  The  DAPMO  representative  will  be  the  decision  authority  for  all 
procedural  or  technical  issues. 

(2)  The  FDAd,  who  has  stewardship  over  the  subject  area  that  is  the 
data  topic  for  the  rapid  data  standardization  project,  shall  be  the  decision  authority  for 
intrafunctional  or  cross-functional  issues. 

g.  Issue  resolution  outside  the  rapid  data  standardization  collaborative  session 
will  be  kept  to  a  minimum.  Issues  that  will  be  decided  outside  the  collaborative  sessions 
include: 


(1)  Issues  that  adversely  affect  readiness  or  inability  to  comply  with  the 
law.  These  issues  will  be  tabled  and  brought  to  the  attention  of  the  appropriate  OSD  PSA  for 
resolution. 

(2)  Data  stewardship  assignment,  and  conflicting  functional  and 
technical  issues.  These  issues  will  be  documented  and  brought  to  the  attention  of  the  DoD 
DAd  for  resolution  within  48  hours. 

(3)  Issues  that  can  not  be  resolved  by  participants  in  the  collaborative 
session.  When  a  resolution  is  unattainable,  it  will  be  brought  to  the  attention  of  the 
ASD(C3I). 


h.  The  output  of  rapid  data  standardization  collaborative  sessions  is 
functionally  and  technically  reviewed  candidate  data  in  data  model  proposal  packages  ready 
for  formal  review. 

4.  Formal  Reviews 

The  formal  review  process  is  covered  in  detail  under  Section  D,  Formal 

Review. 
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c. 


PRELIMINARY  AND  INFORMAL  REVIEWS 


!  Prepare  a  Proposal  Package  and  Conduct  a  Preliminary  Review 

a  The  purpose  of  a  proposal  package  is  to  submit  models  being  proposed 
to  extend  or  update  the  DoD  Enterprise  Data  Model.  An  update  may  increase  or  decrease  the 
number  of  data  objects  in  the  DoD  Enterprise  Data  Model.  The  proposal  package  is  require 
to  begin  the  DoD  Enterprise  Data  Model  review  process.  Proposal  package  size,  contents, 
and  media  for  submission  are  discussed  in  greater  detail  in  Chapter  5. 

b  Ideally,  the  package  should  propose  a  data  model/model  subset  based  on 
a  tightly  integrated  function  (existing  or  proposed)  or  contained  in  a  single  functional  area. 

The  number  of  entities  and  relationships  will  be  larger  if  the  integrated  function  covers 
multiple  concepts,  activities,  or  functional  areas. 

c.  When  a  large  model  is  being  used  for  a  proposal,  a  number  of  proposal 
packages,  each  based  on  a  partition  of  a  manageable  size,  should  be  prepared  in  accordance 
with  guidance  provided  in  Chapter  5. 

d.  Subsets  of  the  latest  version  of  the  DoD  Enterprise  Data  Model  should 
be  included  in  the  proposal  package  permitting  better,  clearer  definition  of  the  context  of  the 
proposed  entities  and  relationships.  These  standardized  components  will  represent  model  and 
semantic  context  rather  than  additional  work  tasks. 

e.  Any  person  within  DoD  or  representing  a  DoD  organization  (i.e., 
originator)  may  propose  to  extend  or  update  the  DoD  Enterprise  Data  Model  by  preparing  and 
submitting  a  proposal  package  for  preliminary  review.  A  proposal  package  can  only  be 
submitted  for  formal  review  by  the  FDAd  designated  as  the  proposal  package  functional  data 
steward.  When  preparing  the  package,  the  originator  is  responsible  for  ensuring  that: 

(1)  The  package  is  complete  and  contains  the  requirements  described 

in  Chapter  5. 

(2)  The  information  in  the  proposal  package  adheres  to  technical  and 
functional  requirements  as  described  in  Chapter  6  and  in  DoD  8320.1-M-l  (reference  (b)). 

f  The  originator  should  submit  the  proposal  package,  for  preliminary 
review,  to  his/her  respective  FDAd  or  CD  Ad  in  accordance  with  Functional  or  Component 
procedures.  Such  procedures  shall  conform  to  DoD  Data  Administration  policies  and 
procedures.  The  appropriate  channels  for  submission  are: 

(1)  Proposals  originating  in  support  of  an  OSD  functional  area  or 
Joint  Warfighting  requirement  will  be  submitted  to  the  respective  FDAd. 
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(2)  Proposals  originating  within  a  Component  or  at  the  component 
level  will  be  submitted  to  the  CDAd. 

g.  Upon  receipt  of  the  proposal  package,  the  FDAd  or  CDAd  will  conduct 
a  preliminary  review.  The  preliminary  review  ensures  that  the  proposal  package  adheres  to 
the  content  requirements  outlined  in  Chapter  5  and  technical  and  functional  requirements 
described  in  Chapter  6.  Guidelines  on  the  functional  and  technical  components  of  reviews  are 
described  later  in  this  chapter. 

h.  During  the  preliminary  review,  proposed  entities  are  reconciled  with  the 
current  DoD  Enterprise  Data  Model.  Guidelines  on  entity  reconciliation  are  addressed  below. 

i.  Either  the  FDAd  or  the  CDAd  will  review  the  proposal  as  follows: 

(1)  The  FDAd  will  perform  a  preliminary  review  of  the  proposal  to 
ensure  compliance  with  Functional  and  DoD  Data  Administration  rules  and  procedures;  or 

(2)  The  CDAd  will  perform  a  preliminary  review  of  the  proposal  at 
the  DoD  component  level  to  ensure  compliance  with  Component  and  DoD  Data 
Administration  rules  and  procedures.  The  Component's  functional  representatives  are 
encouraged  to  discuss  the  proposals  with  their  DoD  functional  counterparts  before  submitting 
the  proposals  to  the  CDAd  and  during  the  Component  preliminary  review. 

j.  Functional  data  stewardship  assignments  are  validated  and/or  made 
during  the  preliminary  review.  The  proposal  package  functional  data  steward  will  be  the 
primary  coordinator  for  the  informal  review  and  will  work  with  the  originator,  submitting 
FDAd  or  CDAd,  entity  and  attribute  functional  data  stewards,  the  DoD  DAd,  and  SMEs 
during  all  subsequent  reviews.  The  entity  and  attribute  functional  data  stewards  will  help 
coordinate  questions,  issues,  and  support  maintenance  for  the  individual  entities  and  attributes 
that  they  represent.  If  issues  exist  for  a  functional  data  stewardship  assignment,  the  DoD 
DAd  should  be  consulted  for  a  resolution.  Guidance  for  assigning  functional  data  stewards  is 
discussed  in  Chapter  2. 

k.  Upon  completing  the  preliminary  review,  the  FDAd  or  CDAd  will 
submit  the  proposal  for  informal  review  to  the  FDAd  designated  as  the  proposal  package 
functional  data  steward.  A  copy  of  the  proposal  package  will  be  furnished  to  the  DoD  DAd. 

2.  Conduct  an  Informal  Review 


a.  The  FDAd  designated  as  the  proposal  package  functional  data  steward,  with 
guidance  from  the  DoD  DAd,  will  conduct  an  informal  review  upon  receipt  of  the  proposal 
package.  The  informal  review  consists  of  both  functional  and  technical  reviews  and  ensures 
that  the  proposed  model/model  subset  adheres  to  mandatory  technical  and  functional 
requirements  described  in  Chapter  6.  The  contents  of  the  proposal  package  will  also  be 
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reviewed  to  ensure  that  the  content  requirements  outlined  in  Chapter  5  have  been  met. 
Guidelines  on  the  functional  and  technical  aspects  of  the  reviews  are  discussed  below. 

b.  The  DoD  DAd  will  coordinate  with  the  FDAd  designated  as  the  proposal 
package  functional  data  steward  to  establish  a  strategy  and  plan  for  reviewing  the  proposed 
model/model  subset  and  providing  feedback  to  the  submitting  CDAd  or  FDAd.  The  FDAd 
designated  as  the  proposal  package  functional  data  steward  will  track  the  status  of  the 
proposal  and  keep  the  submitting  FDAd  or  CDAd  informed  of  progress  and  results. 

c.  The  proposal  package  functional  data  steward,  or  a  designated 
representative,  should  enter  all  new  or  modified  entities  (prime  words),  attributes  (data 
elements),  and  associated  required  metadata  into  the  DDRS  during  this  review.  The  status  of 
these  prime  words  and  data  elements  will  be  developmental.  Prime  words  and  data  elements 
in  the  DDRS  can  be  accessed  and  reviewed  by  other  reviewers.  Access  to  the  DDRS  can  be 
requested  for  all  stakeholders  who  do  not  already  have  access,  through  the  DAPMO.  The 
DDRS  provides  automated  support  for  the  review  process  and  entry  of  prime  words  and  data 
elements  is  the  first  step  towards  preparing  for  formal  review. 

d.  Proposal  package  functional  data  stewards  should  coordinate  with  entity  and 
attribute  functional  data  stewards,  FAPMs,  OSD  PSAs,  DoD  Fibs,  and  other  SMEs  to  ensure 
that  their  views  are  fully  represented.  The  functional  data  stewards  are  also  encouraged  to 
discuss  proposals  with  functional  counterparts  within  Components,  CDAds,  and  the  proposal 
originator. 


e.  The  informal  review  is  a  critical  process  in  the  development  of  the  DoD 
Enterprise  Data  Model.  It  is  designed  to  ensure  the  quality  of  the  model  proposal  before  it  is 
submitted  for  formal  review.  The  goal  of  the  informal  review  is  to  ensure  that  the  proposal 
adheres  to  functional  and  technical  requirements.  The  FDAd  designated  as  the  proposal 
package  functional  data  steward  and  the  DoD  DAd  will  coordinate  efforts  to  ensure  that 
technical  standards  are  consistently  applied,  functional  and  technical  reviews  are  conducted  in 
concert,  and  technical  issues  are  resolved.  The  proposal  package  functional  data  steward  shall 
apply  technical  standards  during  each  functional  review.  The  DoD  DAd  will  conduct 
technical  reviews,  provide  feedback,  and  resolve  technical  issues,  as  needed. 

f.  The  informal  review  is  an  iterative  process  to  ensure  that  functional  and 
technical  reviews  are  conducted  concurrently.  Over  time,  it  is  expected  that  as  experience  is 
gained,  lessons  are  learned,  and  functional  area  data  models  are  completed,  the  number  of 
iterations  between  functional  and  technical  reviews  should  decrease  dramatically  and  the  need 
for  an  informal  review  will  diminish. 

g.  During  the  informal  review,  all  efforts  will  be  taken  by  the  FDAd 
designated  as  the  proposal  package  functional  data  steward,  to  avoid  rejecting  the  proposal. 
The  DoD  DAd  will  work  with  the  proposal  package  functional  data  steward  to  clarify 
technical  issues  and  resolve  conflicts.  There  are  some  occasions,  however,  where  it  may  be 


4  -  10 


more  efficient  to  reject  all  or  part  of  a  proposal  and  return  it  to  the  submitter.  All  or  part  of  a 
proposal  can  be  rejected  for  the  following  reasons: 

(1)  Incomplete  or  incorrect  proposal  package  contents. 

(2)  Unreconcilable  technical  and/or  functional  problems. 

h.  If  all  or  part  of  a  proposal  package  is  rejected,  it  will  be  returned  to  the 
submitter  with  reason(s)  for  the  rejection  and  suggestions  for  improvement.  When  this 
happens,  the  submitter  may  address  the  informal  review  comments  and  resubmit  the  proposal. 
The  FDAd  will  notify  the  DoD  DAd  of  actions  taken  against  rejected  proposals. 

i.  The  FDAd  will  notify  the  DoD  DAd  when  proposals  are  ready  for  formal 
review  and  provide  functional  recommendations.  Proposals  that  have  not  undergone  a 
technical  review  by  the  DoD  DAd  may  not  be  submitted  for  formal  review.  The  FDAd  may 
submit  proposals  for  formal  review  when: 

(1)  The  FDAd  and  DoD  DAd  both  agree  that  functional  and  technical 
requirements  have  been  met. 

(2)  The  FDAd  feels  that  functional  requirements  have  been  met,  but  the 
DoD  DAd  feels  that  technical  requirements  have  not  been  met. 

D.  FORMAL  REVIEW 

1 .  The  formal  review  process  will  be  conducted  within  40  workdays.  The  formal 
review  process  consists  of: 

a.  Preparing  a  formal  review  package  (1-10  workdays), 

b.  Conducting  the  cross-functional  review  (1-20  workdays),  and 

c.  Evaluating  results  of  the  formal  review  (1-10  workdays)  and  resolving 

issues. 


2.  The  formal  review  ensures  that  the  proposed  DoD  Enterprise  Data  Model 
entities  and  relationships  are  represented  uniformly  with  a  DoD  perspective.  This  review 
provides  all  DoD  FDAds  and  CDAds  the  opportunity  to  review  the  proposed  extensions  to  the 
DoD  Enterprise  Data  Model  from  a  cross-functional  perspective.  The  DoD  DAd  evaluates 
any  recommendations  generated  during  the  cross-functional  review  and  decides  to  approve, 
disapprove,  or  submit  issues  for  resolution.  Throughout  the  formal  review  process,  the  DoD 
DAd  will  monitor  the  status  of  each  proposal.  See  Section  E  of  this  chapter  for  guidelines  to 
be  applied  when  conducting  reviews. 
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3.  Prepare  Formal  Review  Package 

Within  10  workdays  of  receiving  proposal  package  functional  data  steward 
notification,  the  DoD  DAd  will  prepare  a  formal  review  package  consisting  of  the  proposed 
DoD  Enterprise  Data  Model,  information  from  the  original  proposal  package,  functional 
recommendations,  and  technical  review  results.  The  proposed  DoD  Enterprise  Data  Model  is 
prepared  by  integrating  the  proposed  model  view  with  the  current  DoD  Enterprise  Data 
Model.  See  Section  F,  below,  for  guidelines  on  integrating  data  models.  Preparation  for 
formal  review  also  includes  changing  the  status  of  proposed/modified  prime  words  (entities) 
and  data  elements  (attributes)  to  Candidate  in  the  DDRS.  The  DoD  DAd  will  send  the  formal 
review  package  to  all  FDAds  and  CDAds  and  officially  notify  them  of  the  formal  review  via 
the  DDRS.  If  the  proposal  contains  proposed  modifications  to  approved  DoD  Enterprise  Data 
Model  entities  (prime  words)  and  attributes  (data  elements),  then  the  proposal  package  will 
also  be  sent  to  users  of  the  prime  words  and  data  elements  registered  in  the  DDRS. 

4.  Conduct  Cross-Functional  Review 

a.  The  cross-functional  review  will  be  completed  within  20  workdays  of 
official  notification.  The  review  period  begins  on  the  first  full  day  after  notification  is  sent 
out.  The  cross-functional  review  ensures: 

(1)  The  candidate  entity(ies)  and  attribute  metadata  are  clear, 
meaningful,  and  consistent  with  cross-functional  area  mission  and  information  requirements, 

(2)  The  candidate  entity(ies)  and  associated  attributes  are  represented 
uniformly  with  a  DoD  perspective  so  that  they  can  be  interpreted  consistently, 

(3)  The  candidate  entity(ies)  and  associated  attributes  conform  to  the 
technical  standards  described  in  Chapter  6  and  in  DoD  8320.1-M-l  (reference  (b)),  and 

(4)  The  entity  relationships  accurately  reflect  business  rules  that  are 
implemented  uniformly  with  a  DoD  perspective. 

b.  The  cross-functional  review  package  will  contain  a  hardcopy  of  the  overall 
model  ERD  and  proposal  package  model  subset  ERD  (if  applicable),  and  a  list  of 
proposed/modified  prime  word  and  data  element  names  in  the  proposal  with  DDRS  Counter 

Identifiers. 


c.  Reviewers  should  look  over  the  ERD  and  examine  the  prime  words,  data 
elements,  descriptions,  and  all  associated  metadata  in  the  DDRS. 

d.  FDAds  are  responsible  for  coordinating  with  FAPMs,  OSD  PSAs,  DoD 
Fibs,  and  other  SMEs  to  ensure  that  their  views  are  fully  represented.  FDAds  are  required  to 
review  and  provide  comments  within  the  specified  timeframe.  No  response  indicates 
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concurrence. 


e.  CDAds,  representing  their  Component's  interest,  may  review  the  proposal 
but  are  not  required  to  provide  comments.  They  are  also  encouraged  to  coordinate  with 
functional  area  experts  within  the  component  organization  they  represent  to  ensure  that  their 
views  are  fully  represented. 

f.  Comments  may  be  returned  in  writing  or  through  the  DDRS. 

g.  Rejection  of  all  or  part  of  a  proposal  shall  be  supported  by: 

(1)  A  full  justification  including  documentation  (source  regulations, 
mission  statements,  official  policy,  DoD  Directives,  Laws,  etc.)  to  support  the  rejection. 

(2)  One  or  more  technically  and  functionally  compliant,  DoD-consistent 

alternatives. 


h.  Comments  received  after  the  20-day  window  may  not  be  accepted. 
5.  Evaluate  Results  of  Cross-Functional  Review 


a.  The  DoD  DAd  evaluates  the  recommendations  from  the  cross-functional 
review.  The  purpose  of  the  evaluation  is  to  obtain  consensus  with  the  FDAd  designated  as 
the  proposal  package  functional  data  steward  on  a  final  decision.  The  final  evaluation  should 
be  conducted  within  10  workdays  after  completing  the  cross-functional  review. 

b.  The  DoD  DAd  will  coordinate  with  the  FDAd  designated  as  the  proposal 
package  functional  data  steward  to  resolve  functional  and  technical  issues  that  were  raised 
during  the  cross-functional  review.  Although  all  efforts  will  be  made  by  the  DoD  DAd  to 
resolve  issues  within  10  workdays,  the  issues  may  be  coordinated  for  a  longer  period  of  time 
at  the  discretion  of  the  DoD  DAd. 

c.  Based  upon  the  results  of  the  evaluation  and  coordination,  the  DoD  DAd 
will  either  approve  or  disapprove  the  proposed  extensions/modifications  to  the  DoD  Enterprise 
Data  Model  and  resulting  prime  word(s)  or  forward  issues  for  resolution. 

(1)  When  the  proposed  DoD  Enterprise  Data  Model  is  approved,  the 
DoD  DAd  will  change  the  status  of  the  affected  candidate  prime  word(s)  in  the  DDRS  to 
Approved.  The  DoD  DAd  will  notify  the  OSD  PSAs  and  the  FDAd  designated  as  the 
proposal  package  functional  data  steward  of  the  approval.  The  steward,  in  turn,  will  notify 
the  submitter  of  the  change  in  status. 

(2)  When  the  proposed  DoD  Enterprise  Data  Model  is  disapproved,  the 
DoD  DAd  will  change  the  status  of  the  affected  candidate  prime  word(s)  in  the  DDRS  to 
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disapproved.  The  FDAd  designated  as  the  proposal  package  functional  data  steward  will 
notify  the  submitter  of  the  disapproval  and  any  recommended  actions.  Either  the  originator, 
the  submitter,  or  the  proposal  package  functional  data  steward  may  elect  to  make  the 
necessary  changes  to  the  proposal  package  and  resubmit  the  package  for  informal  review. 

(3)  Issues  requiring  resolution  will  be  forwarded  to  the  DASD(IM). 
d.  Resolve  Issues 

(1)  The  only  time  that  extensions,  modifications,  and  new  versions  of 
the  DoD  Enterprise  Data  Model  will  come  before  the  DASD(IM)  will  be  when  there  are 
issues  to  be  resolved. 

(2)  The  DoD  DAd  will  forward  issues  for  resolution  along  with 
recommendations  to  the  DASD(IM).  The  DASD(IM)  will  resolve  the  issue  and  notify  the 
DoD  DAd  and  the  FDAds  of  the  decision. 

(3)  The  DASD(IM)  will  consult  with  the  OSD  PSAs  as  needed  to 
gather  information  and  recommendations  since  they  were  consulted/participated  in  the 
preparation  and  informal  review  of  the  proposal  packages. 

(4)  If  the  DASD(IM)  cannot  resolve  an  issue,  it  will  be  given  to  the 
Defense  Senior  IM  Official  ASD(C3I)  for  resolution  or  forwarded  to  the  Deputy  Secretary  of 
Defense  for  final  resolution. 

(5)  The  DAPMO  will  record  all  issues,  options,  and  decisions.  For 
future  justification  and  reference,  the  DAPMO  will  record  who  made  them  and  the  rational 
behind  them. 

E.  FI  INCTIONAT  AND  TECHNICAL  REVIEWS 

1.  The  functional  and  technical  components  of  model  reviews  are  needed  to  ensure 
the  quality  of  the  DoD  Enterprise  Data  Model.  These  reviews  are  conducted  throughout  the 
DoD  Enterprise  Data  Model  development  and  approval  process  at  all  levels  of  data 
administration. 

2.  Reviews  are  conducted  by  CDAds,  FDAds,  and  the  DoD  DAd.  Other  functional 
stakeholders,  and  SMEs  contribute  to  these  reviews  through  coordination  with  the  FDAds, 
CDAds,  and  the  DoD  DAd. 

3.  Regardless  of  the  type  of  review  or  who  is  conducting  the  review,  the  goal  of  any 
DoD  Enterprise  Data  Model  review  is  the  same:  "To  ensure  the  proposed  entities,  attributes, 
and  relationships  adhere  to  mandatory  technical  and  functional  requirements  and  are 
represented  uniformly  with  a  DoD-wide  perspective."  Each  review  is  conducted  as  a 
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coordinated  iterative  process  whereby  functional  and  technical  standards  are  consistently 
applied.  Reviews  are  also  conducted  to  ensure  the  proposal  package  contains  all  required 
information  and  to  resolve  issues. 

4.  Approval  procedures  for  attributes  provided  in  this  document  are  supportive  of 
approval  procedures  for  data  element  standards  provided  in  DoD  8320.1-M-l  (reference  (b)), 
but  do  not  replace  data  standardization  approval  procedures.  Data  element  standardization 
approval  procedures  should  be  conducted 

simultaneously  with  data  model  approval  procedures  to  ensure  that  standard  data  element 
specifications  match  attribute  descriptions. 

5.  Functional  and  Cross-Functional  Review 


a.  The  functional  review  ensures  that  entity  (prime  word)  and  attribute  (data 
element)  definitions  are  clear,  meaningful,  and  consistent  with  functional  area  objectives.  The 
cross-functional  review  ensures  that  the  entity  and  attribute  are  represented  uniformly  with  a 
DoD  perspective  and  that  the  metadata  and  business  rules  expressed  in  entity  relationships  are 
consistent  DoD-wide. 

b.  FDAds  are  primarily  responsible  for  conducting  functional  reviews,  as 
functional  data  stewards,  and  participating  in  cross-functional  reviews.  The  CDAd  contributes 
to  the  informal  functional  reviews,  and  although  not  required,  may  also  participate  in 
cross-functional  reviews.  When  conducting  functional  reviews,  the  FDAds  should  coordinate 
with  OSD  PSAs,  FAPMs,  DoD  Fibs,  and  SMEs  to  ensure  that  they  are  fully  represented. 

They  are  also  encouraged  to  coordinate  with  functional  counterparts  in  the  Components, 
CDAds,  the  proposal  originator  and  any  users  of  the  proposed  entities  (prime  words)  and 
attributes  (data  elements)  known  and/or  registered  in  the  DDRS. 

c.  During  the  functional  review,  the  FDAd,  designated  as  the  proposal  package 
functional  data  steward,  and  the  DoD  DAd  shall  coordinate  efforts  to  ensure  that  technical 
standards  are  consistently  applied,  functional  and  technical  reviews  are  conducted  in  concert, 
and  technical  issues  are  resolved. 

d.  The  goals  of  both  functional  and  cross-functional  reviews  are  to  accomplish 

the  following: 

(1)  Encompass  the  work  and  view  of  the  functional  areas. 

(2)  Identify  appropriate  functional  experts  from  whom  to  seek 

assistance. 

(3)  Obtain  cross-functional  agreement  on  entity  and  attribute 

definitions. 
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(4)  Identify  the  DoD  office  having  primary  responsibility  for  the  data 
represented  (data  steward). 

(5)  Discuss  and  possibly  identify  new  entities,  attributes,  and  data 

stewards. 

(6)  Validate  the  need  for  entities  and  attributes  within  the  framework  of 
the  DoD  Enterprise  Data  Model. 

(7)  Discuss  and  validate  entity  relationships. 

(8)  Document  how  entity  attribute  definitions  were  validated  and 

agreed  upon. 

(9)  Ensure  uniqueness  of  entities  and  attributes. 

(10)  Validate  the  proposed  integrated  DoD  Enterprise  Data  Model. 

(11)  Ensure  that  technical  standards  are  continuously  applied. 

6.  Technical  Review 

a.  During  the  technical  review,  the  proposed  entities  and  attribute  are  reviewed 
to  ensure  that  they  conform  to  DoD  Data  Administration  requirements  and  do  not  conflict 
with  existing  approved,  candidate,  or  modified  entities.  The  technical  review  applies  the  rules 
for  entity  and  attribute  design,  definition,  and  naming.  Before  the  cross-functional  review  can 
be  performed,  the  DoD  DAd  also  performs  an  impact  analysis  and  validates  and/or  integrates 
the  proposed  extension  or  changes  with  the  current  DoD  Enterprise  Data  Model  to  create  a 
new  proposed  integrated  view.  See  Section  F,  below,  for  guidelines  on  integrating  data 
models. 

b.  FDAds  shall  continuously  apply  technical  standards  when  conducting  the 
functional  review.  The  DoD  DAd  will  assist  the  FDAds  by  conducting  technical  reviews, 
providing  feedback,  and  resolving  technical  issues.  The  DoD  DAd  is  responsible  for  ensuring 
that  technical  standards  are  applied  before  entities  are  approved.  The  DoD  DAd  will  conduct 
a  technical  review  on  every  entity  before  it  is  submitted  as  a  candidate  entity. 

c.  The  goals  of  the  technical  review  are  to  accomplish  the  following: 

(1)  Further  ensure  that  the  candidate  entity  and  attributes  do  not 
conflict  with  any  existing  candidate  or  approved  entities  and  attributes. 

(2)  Ensure  that  the  candidate  entity  and  attributes  are  represented 
uniformly  within  the  context  of  DoD  as  a  whole,  rather  than  a  unique  functional  or 
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component  perspective. 

(3)  Validate  and  integrate  the  proposed  model  entities  and  attributes 
with  the  current  DoD  Enterprise  Data  Model  to  create  a  proposed  integrated  view  of  the  DoD 
Enterprise  Data  Model.  See  Section  F,  below,  for  instructions  on  how  to  reconcile  and 
integrate  data  models. 


(4)  Ensure  all  entity  and  attribute  metadata  information  is  complete  and 
conforms  to  the  requirements  set  forth  in  Chapter  6  and  DoD  8320.1-M-l,  (reference  (b)). 


(5)  Validate  entities  within  the  framework  of  the  DoD  Enterprise 


Model. 

(6)  Ensure  that  normalization  and  key  migration  are  correct. 

(7)  Verify  and  evaluate  cardinality  and  relationship  names. 

(8)  Verify  and  assign  functional  stewardship.  The  DoD  DAd  has  final 
say  in  all  data  steward  disputes. 


F.  ENTITY  RECONCILIATION  AND  MODEL  INTEGRATION 


During  all  data  model  reviews  described  above,  proposed  entities  should  be  reconciled 
and  the  proposed  data  model/model  subsets  should  be  integrated  with  the  DoD  Enterprise 
Data  Model  using  procedures  described  below. 

1.  Entity  Reconciliation 

a.  Proposed  entities  shall  be  reconciled  with  the  current  DoD  Enterprise  Data 
Model  as  follows: 


(1)  Confirm  that  a  suitable  entity  does  not  already  exist  by  reviewing 
all  proposed,  approved,  disapproved,  candidate,  modified,  and  archived  entities  that  have  the 
same  or  similar  names  or  structure  based  upon  the  definition  and  relationships.  This  process 
compares  proposed  entities  with  those  in  the  DoD  Enterprise  Data  Model  and  designates  the 
pair  as  one  of  the  following: 


(a)  Identical.  There  is  an  exact  match  in  primary  key  attributes, 
nonkey  attributes,  and/or  relationships. 

(b)  Similar.  Adjustments  can  be  made  to  the  proposed  key 
and/or  nonkey  attributes  that  make  the  proposed  entity  identical  to  an  entity  in  the  DoD 
Enterprise  Data  Model.  The  result  of  these  changes  shall  not  alter  "what"  the  proposed  entity 
describes. 
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(c)  Different.  There  is  not  an  identical  or  similar  match  in  the 

DoD  Enterprise  Data  Model. 

(d)  Tdentical/Similar  with  Different  Relationships.  The  DoD 
Enterprise  Data  Model  entity  and  the  proposed  entity  have  identical/similar  attributes, 
properties,  and  keys,  but  there  are  still  nonidentifying  relationship  differences. 

(2)  Determine,  by  comparison,  those  entities  and  attributes  that  are 
identical.  A  comparison  is  done  between  the  proposed  view  and  the  DoD  Enterprise  Data 
Model.  Each  proposed  name  is  compared  with  each  name  in  the  DoD  Enterprise  Data  Model. 
When  an  entity  match  occurs,  a  comparison  is  done  with  the  definition,  relationships,  key 
name,  key  definition,  and  instances  of  each  pair  of  entities.  When  an  attribute  match  occurs, 
further  comparison  is  done  with  the  meta  attribute  information  for  each  pair. 

(3)  Resolve  Svnonvms  and  Homonyms.  Compare  two  names  that  have 
some  degree  of  similarity  either  in  the  name  or  the  definition  or  two  definitions  that  have 
some  degree  of  similarity  with  different  names. 

(4)  Resolve  Relationship  Inconsistencies.  Identify  relationships  that 
duplicate  the  business  rule  or  meanings  within  the  DoD  Enterprise  Data  Model  and 
consolidate  them. 


(a)  Determine  if  a  new  relationship  is  free  of  conflict  with 

existing  relationships. 

(b)  Ensure  the  parent  and  child  direction  is  correct. 

(c)  Resolve  many-to-many  relationships  where  appropriate  for 
improving  the  value  of  the  model  as  a  tool  for  jump  starting  data  modeling  efforts  and 
supporting  functional  integration. 

(d)  Ensure  category  entities  are  a  subset  of  the  fundamental 

entity  definition. 

(5)  After  proposed  entities  and  attributes  are  reconciled,  those  entities 
or  attributes  that  are  identified  as  different,  newly  created,  split,  or  formed  as  new 
categorizations  are  documented  in  the  proposal  package.  If  a  reconciliation  should  produce 
changes  to  the  proposal,  the  FDAd,  CDAd,  or  originator  should  be  involved  to  enhance 
understanding  on  both  sides  and  improve  the  quality  of  the  product. 

(6)  Entities  and  attributes  that  cannot  be  resolved  by  the  FDAd  or 
CDAd  and/or  originator  are  documented  and  returned  to  the  originator. 

(7)  Accepted  entities  and  attributes  should  be  further  reviewed  to 
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ensure  validity  and  to  check  that  keys  and  relationships  do  not  conflict  or  overlap  with  other 
entities. 

2.  Model  Integration 

a.  The  proposed  data  model  shall  be  integrated  with  the  current  DoD 
Enterprise  Data  Model  to  create  a  proposed  integrated  view.  Integration  also  further 
reconciles  the  entities  and  relationships  with  the  DoD  Enterprise  Data  Model,  modifying  the 
proposal  or  adjusting  the  DoD  Enterprise  Data  Model  based  on  the  new  information. 

b.  Integration  is  the  process  of  combining  and  adapting  two  data  model 
views  to  produce  the  best  optimal  view  with  a  broader  scope.  The  process  creates  a  new 
view  in  compliance  with  data  standards  and  modeling  technique  rules  by  identifying  entities' 
similarities  and  differences.  A  technical  review  is  done  to  ensure  that  normalization  and  key 
migration  is  correct.  The  new  view  is  considered  to  be  the  proposed  integrated  data  model. 

c.  The  resulting  view  shall  uphold  the  following  two  major  aspects  during 

integration: 


(1)  The  business  aspect  shall  continue  to  be  appropriate  to  the  specific 
functional  area.  The  Integration  Team  shall  understand  and  preserve  the  business  view  by 
consulting  with  functional  specialists. 

(2)  The  technical  aspect  shall  be  accurate  and  enforce  rules  of  data 
standards.  The  entity  names  and  definitions  shall  continue  to  conform  to  the  entity  design, 
naming,  and  definition  rules  described  in  Chapter  6.  Attribute  names  and  definitions  shall 
continue  to  conform  to  the  design,  naming,  and  definition  rules  described  in  DoD  8320.1-M-l 
(reference  (b)). 

d.  Integration  with  the  DoD  Enterprise  Data  Model  is  composed  of  three 

processes: 


(1)  Validate  proposal  and  fully  develop  the  proposed  view  into  a 
complete  and  error  free  data  model, 


(2)  Merge  the  proposed  view  with  the  working  copy  of  the  DoD 
Enterprise  Data  Model  to  create  the  proposed  integrated  view,  and 


review. 


(3)  Normalize  the  DoD  Enterprise  Data  Model  to  3NF  for  formal 


e.  These  processes  result  in  proposed  entities  and  attributes  being  assimilated 
into  the  DoD  Enterprise  Data  Model  along  with  relationships  and  primary  keys.  The  resulting 
model  components  shall  be  evaluated  for  correctness  and  assurance  that  a  realistic 
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representation  of  the  DoD  business  is  reflected  after  accommodating  the  changes.  Each 
process  requires  a  review  for  data  standards  compliance  to  ensure  rule  infractions  do  not 
occur  when  changes  are  made  to  entities,  attributes,  or  keys. 


4 
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CHAPTER  5 


PROPOSAL  REQUIREMENTS 


A.  INTRODUCTION 


This  chapter  describes  preparation  of,  and  required  contents  for,  a  proposal  package  to 
extend  or  update  the  DoD  Enterprise  Data  Model.  The  proposal  package  is  used  to  propose  a 
data  model/model  subset  (generally  subset)  based  on  a  tightly  integrated  function  (existing  or 
proposed),  or  contained  in  a  single  subject  area  for  incorporation  into  the  DoD  Enterprise  Data 
Model.  A  series  of  checklists  has  been  developed  to  support  proposal  package  preparation. 
These  checklists  are  presented  in  Appendix  C. 

B.  PROPOSAL  PACKAGE  SIZE 

1 .  Proposal  packages  should  be  of  such  a  size  and  complexity  that  the  proposed  data 
model/model  subset  can  be  understood  and  placed  in  context  with  other  models  containing  related 
functions  or  entities. 

2.  When  a  large  model  is  being  used  for  a  proposal,  it  should  be  partitioned  into 
subsets  that  can  be  submitted  in  multiple  proposal  packages,  each  with  less  than  or  equal  to  20 
entities  and  200  attributes. 

a.  Each  subset  proposal  package  should  be  prepared  in  accordance  with 
guidelines  in  this  chapter. 

b.  Each  subset  of  the  larger  model  should  represent  a  logical  grouping  of 
entities  based  on  related  functional  content. 

c.  The  related  subset  proposal  packages  do  not  need  to  contain  model 
components  that  are  mutually  exclusive. 

d.  An  entity  can  be  proposed  in  more  than  one  subset  proposal  package  when 
the  entity  has  a  large  number  of  relationships  that  extend  across  the  larger  model  into  multiple 
partitions. 


e.  Each  subset  should  attempt  to  capitalize  on  the  current  DoD  Enterprise  Data 
Model  components. 

C.  PROPOSAL  PACKAGE  CONTENTS  AND  MEDIA 

1.  The  proposal  package  shall  include  a  graphic  representation  of  the  model/model 
subset  in  the  form  of  an  ERD.  The  ERD  should  be  submitted  in  both  hardcopy  and  softcopy 
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form  with  a  discussion  of  the  scope,  function,  and  development  technique.  The  preferred 
technique  for  developing  ERDs  is  IDEF1X  (see  discussion  in  Chapter  2,  above).  Regardless  of 
the  technique  used,  the  ERDs  should  be  logical,  attributed  (including  keys),  normalized  data 
models,  or  data  model  subsets  depicting  clusters  of  related  entities.  Relevant  subsets  of  the  latest 
version  of  the  DoD  Enterprise  Data  Model  should  be  included  for  contextual  reference  and 

review. 


2.  If  the  proposal  package  represents  a  partition  of  a  larger  model,  a  graphical  high- 
level  ERD  summarizing  entities  and  relationships  for  the  entire  model  should  be  provided.  This 
ERD  should  identify  the  specific  entities  from  the  overall  model  included  in  the  associated 
proposal  package.  This  high-level  ERD  should  also  be  submitted  in  hardcopy  and  softcopy  with 
a  discussion  of  the  scope,  functional  partitioning  approach,  and  development  technique. 

3.  The  proposal  package  shall  also  include  a  list  of  all  entities,  attributes,  and  DDRS 
Counter  Identifiers.  This  list  should  include  relevant,  approved  DoD  Enterprise  Data  Model 
entities  and  attributes  from  the  latest  version  of  the  DoD  Enterprise  Data  Model.  This 
information  will  provide  a  better,  clearer  definition  of  the  context  of  the  proposed  entities  and 
their  relationships  to  the  DoD  Enterprise  Data  Model.  The  list  of  entities  and  attributes  will  be 
distributed  with  the  graphical  model  diagrams  discussed  above,  to  assist  reviewers  in  locating  and 
reviewing  proposed  entities  and  attributes  in  the  DDRS  during  the  formal  cross-functional  review. 

4.  If  there  is  some  technical  reason  why  entities,  attributes,  and  associated  metadata 
cannot  be  entered  into  the  DDRS,  this  information  will  be  accepted  in  hard  and  softcopy  format. 
The  preferred  format  for  softcopy  delivery  of  this  information  is  the  DDRS  Batch  Input  Format. 
This  format  is  defined  in  the  DDRS  End  User  Manual  (reference  (k)),  which  is  available  from 
the  DAPMO. 

5.  Information  entered  into  the  DDRS  does  not  need  to  be  provided  in  hardcopy  or 
softcopy  with  the  proposal  package,  with  the  exception  of  the  list  of  entities,  attributes,  and 
DDRS  counter  identifiers  discussed  above.  Information  not  entered  into  the  DDRS  should  be 
provided  in  hardcopy  and  softcopy  with  the  proposal  package  diagrams  discussed  above.  This 
includes  basic  package  information,  relationship  information,  and  attribute  role  names. 

D.  BASIC  PACKAGE  INFORMATION 

Each  proposal  package  should  contain  the  following  basic  information: 

1.  DoD  Sponsoring  Organization.  The  DoD  sponsoring  organization  is  the 
organization  that  developed  the  proposal.  The  originator  or  point  of  contact  is  the  person  who 
is  representing  the  sponsoring  organization.  The  originator  should  provide  his/her  name  and  the 
organization's  name,  address,  and  telephone  number.  The  originator's  organization  shall  be  a 
DoD  organization  or  represent  the  DoD  sponsoring  organization. 

2.  Version  Number  of  the  DoD  Enterprise  Data  Model.  The  version  number,  which 
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includes  the  date  of  publication,  will  be  used  to  identify  the  version  of  the  DoD  Enterprise  Data 
Model  that  the  proposal  will  modify. 

3.  FDAd  or  CD  Ad's  Name  and  Organization.  The  FDAd  or  CDAd  is  the  person  who 
received  the  proposal  package  from  the  originator.  This  person  will  review  and  coordinate  all 
proposal  packages  for  the  organizations  within  his/her  functional  area  or  Component. 

4.  FDAd  designated  as  the  proposal  package  functional  data  steward. 

5.  Functional  area  identification  code  for  the  functional  area  responsible  for  all  or 
most  of  the  data  items  being  proposed  in  the  package  to  extend  the  DoD  Enterprise  Data  Model. 

6.  Model  Component  Count.  This  count  is  the  number  of  each  type  of  model 
components  (i.e.,  number  of  entities,  number  of  attributes,  and  number  of  relationships).  This 
information  will  help  determine  the  size  and  complexity  of  the  model  under  review. 

7.  Name  of  the  tool  used  to  generate  the  ERD  and  reports  along  with  a  description 
of  the  information  and  format  of  the  softcopy. 

8.  Identification  of  any  information  systems  supported  by  the  ERD. 

9.  Proposal  packages  based  on  non-IDEFIX  data  models  shall  provide  the  following 
information  in  addition  to  the  other  information  specified  in  this  chapter: 

a.  The  technique  used  to  develop  the  ERD. 

b.  The  type  of  schema  (i.e.,  conceptual,  internal,  or  external  as  defined  in 
Chapter  2)  and  the  notations  used  in  the  ERD. 

E.  REQUIRED  ENTITY  INFORMATION 

All  proposed  entities,  attributes,  and  relationships  should  be  depicted  on  an  ERD  that 
represents  a  model/model  subset  of  related  entities.  Entity  information  discussed  below  shall 
comply  with  the  technical  and  functional  requirements  specified  in  Chapter  6.  Entering  entity 
information  into  the  DDRS  is  the  first  step  towards  reviewing  and  approving  prime  words  for  use 
in  DoD  8320.1-M-l  (reference  (b)). 

1.  Entity  name. 

2.  Entity  Definition. 

3.  Proposed  entity  functional  data  steward. 

4.  Functional  area  identification  code. 
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5.  Attribute  names  including  any  key  designations  (primary  key,  foreign  key,  alternate 
key,  or  candidate  key). 

6.  Entity  Submission  Type.  For  each  entity,  identify  whether  it  is  developmental, 
candidate,  modified,  archived,  or  reinstated: 

a.  Developmental.  Proposed  for  preliminary  or  informal  review, 

b.  Candidate.  Submitted  for  formal  review, 

c.  Modified.  An  approved  entity  in  the  DoD  Enterprise  Data  Model  that  is 
being  modified, 

d.  Archived.  An  approved  entity  in  the  DoD  Enterprise  Data  Model  that  is 
recommended  for  archival,  or 

e.  Reinstated.  An  archived  entity  that  is  recommended  for  reinstatement  to 
the  DoD  Enterprise  Data  Model. 

7.  Prime  word  using  model  name. 

F.  REQUIRED  ATTRIBUTE  INFORMATION 

For  each  entity  in  the  proposal,  the  following  attribute  information  is  needed  and  should 
be  entered  into  the  DDRS.  Identifying  and  entering  this  information  into  the  DDRS  is  the  first 
step  toward  reviewing  and  approving  these  attributes  as  DoD  standard  data  elements.  Information 
identified  below  shall  comply  with  the  technical  and  functional  requirements  specified  in  DoD 
8320.1-M-l  (reference  (b)). 

1.  Attribute  Names  and  Definitions.  For  each  attribute,  identify  whether  it  is  a 
primary  key,  alternate  key,  foreign  key,  or  nonkey  attribute. 

2.  Attribute  Metadata  Information.  Provide  the  following  metadata  information  for 
each  attribute.  Detailed  descriptions  of  this  information  can  be  found  in  DoD  8320.1-M-l 
(reference  (b)). 

a.  Data  value  source  list  text. 

b.  Decimal  place  count  quantity. 

c.  Authority  reference  text. 

d.  Domain  definition  text. 
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e.  Domain  value  identifiers. 

f.  Domain  value  definition  text. 

g.  High-range  identifier  (quantitative  only). 

h.  Low-range  identifier  (quantitative  only). 

i.  Maximum  character  count  quantity. 

j.  Security  classification  code. 

k.  Proposed  attribute  functional  data  steward. 

l.  Functional  area  identification  code. 

m.  Unit  Measure  Name  (when  applicable-).  When  unit  of  measure  name  is 
applicable  and  more  than  one  possible  unit  of  measure  exists,  two  documentation  options  exist. 
If  the  unit  of  measure  is  convertible  to  other  units  of  measure  through  standard  algorithm  (i.e., 
distance:  feet  to  meters),  then  the  single  most  commonly  used  unit  of  measure  should  be  entered 
into  this  metadata  field.  If  multiple  possible  units  of  measure  exist  that  cannot  be  converted 
using  standard  algorithms  (i.e.,  cable  quantity:  cable  by  weight  to  cable  by  length),  then  a 
separate  attribute  (data  element)  should  be  added  for  managing/tracking  the  appropriate  unit  of 
measure  for  each  instance  of  the  entity. 

n.  Data  type  name. 

o.  Derivation  type  name. 

p.  Formula  definition  text. 

G.  REQUIRED  RELATIONSHIP  INFORMATION 

1 .  Identify  relationships  between  proposed  entities. 

a.  All  known  relationships  between  proposed  entities  shall  be  identified. 

b.  New  independent  entities  may  exist  and  be  submitted  without  association 
to  other  proposed  entities.  This  provides  functional  area  modelers  the  flexibility  to  identify,  get 
exposure  for,  and  get  feedback  on  new/future  information  requirements  as  they  are  identified. 
Relationships  associated  with  these  entities  should  be  added  as  they  are  identified  through  entity 
maintenance  proposals.  Entity  maintenance  is  discussed  in  Chapter  6. 

2.  Identify  relationships  to  existing  entities  in  the  DoD  Enterprise  Data  Model. 
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3.  Describe  the  business  rule,  including  cardinality  in  terms  of  degree  and  nature  for 
each  relationship.  Any  additional  business  rules  should  be  provided. 
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CHAPTER  6 


ENTITY  DESIGN.  NAMING.  AND  DEFINITION  RULES 

A.  INTRODUCTION 


This  chapter  provides  guidance  for  designing,  defining,  and  naming  entities; 
normalizing  data  models;  and  identifying  primary  key  attributes.  Specific  rules  for  designing, 
defining,  and  naming  attributes  are  identical  to  the  rules  for  data  elements  described  in  DoD 
8320.1-M-l  (reference  (b)). 

B.  ENTITY  DESIGN  RULES 


The  quality  of  the  data  model  is  key  to  the  sound  foundation  for  data  standardization 
and  for  sharing  data  both  cross-functionally  and  within  a  functional  area.  Unless  proper 
consideration  is  given  to  the  creation,  naming,  and 

definition  of  entities,  the  level  of  quality  needed  to  improve  data  sharing  across  the  resulting 
data  structures  will  be  forfeited.  The  definition  and  naming  of  an  entity  is  an  iterative  design 
process  with  the  definition  and  entity  name  often  being  modified  as  the  entity  is  being 
developed.  The  following  rules  are  important  to  the  quality  of  entities: 

1.  The  entity  design  should  be  based  on  functional  information  requirements  in 
support  of  the  mission  and  enterprise. 

2.  An  entity  should  be  designed  according  to  logical  and  not  physical 
characteristics.  Physical  characteristics  include  any  connotations  regarding  technology 
(hardware  or  software),  physical  location  (databases,  files,  reports,  forms  or  tables), 
organization  (functional  data  steward,  components,  projects  or  departments),  or  application 
(systems,  applications,  or  programs). 

3.  An  entity  should  be  created  based  on  the  information  requirement.  The  entity 
definition  should  describe  what  it  is  rather  than  how,  where,  and  when  it  is  used.  The  entity 
should  be  named  according  to  its  definition  and  represent  a  single  concept. 

4.  There  should  be  no  overlap  or  redundancy  of  independent  entities  in  either  the 
proposed  model  or  the  DoD  Enterprise  Data  Model.  For  example,  CAR,  VEHICLE,  TRUCK, 
and  AUTOMOBILE  represent  overlapping  concepts  that  should  not  appear  as  independent 
entities.  Independent  entities  should  be  mutually  exclusive  (e.g.,  FACILITY,  PERSON,  and 
BUDGET  represent  three  mutually  exclusive  concepts). 

5.  Normalization  Rules.  Data  model  normalization  rules  based  on  set  theory  for 
relational  database  design  shall  be  applied  to  all  entities  in  all  logical  data  models.  Entities 
shall  be  normalized  to  First,  Second,  and  Third  Normal  Form  (INF,  2NF,  and  3NF)  (Note: 
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Fourth  and  Fifth  Normal  Form  (4NF  and  5NF)  are  optional).  Applying  normalization  rules  to 
a  model  often  results  in  changes  in  the  placement  of  attributes,  the  primary  key  structure  of 
many  entities,  and  the  definition  of  business  rules.  Applying  the  following  rules  will  promote 
accuracy  and  integrity  of  data  structures. 

q  First  Normal  Form  C1NF).  An  entity  shall  be  defined  as  a  table  where 
all  instances  (rows)  have  the  same  number  of  columns.  No  entity  can  have  attributes  with 
multiple  values  that  result  in  variable  length  records  (e.g.,  First  Award  Name,  First  Award 
Date,  Second  Award  Name,  Second  Award  Date).  Each  attribute  has  only  one  value. 

Second  Normal  Form  C2NF).  When  a  primary  key  consists  of  several 
attributes,  no  subset  of  the  primary  key  should  determine  the  value  of  a  nonkey  attribute.  All 
nonkey  attributes  shall  be  dependent  on  all  of  the  primary  keys  (i.e.,  the  value  of  a  nonkey 
attribute  cannot  be  learned  from  knowing  values  for  only  part  of  the  primary  key). 

EXAMPLE 

Consider  a  PROJECT  ACCOUNT  entity  with  the  attributes  project  identifier,  person 
identifier,  hours  worked,  and  person  address.  The  key  consists  of  project  identifier  and  person 
identifier.  Hours  worked  is  determined  by  both  the  project  identifier  and  person  identifier,  but 
person  address  is  determined  only  by  person  identifier.  To  conform  to  2NF,  Person  Address 
should  be  moved  to  a  separate  entity  keyed  only  by  Person  identifier. 

c  Third  Normal  Form  (3NF).  No  nonkey  attribute  in  an  entity  should 
determine  the  value  of  another  nonkey  attribute.  The  value  for  any  nonkey  attribute  should 
depend  only  on  the  primary  key. 

EXAMPLE 

Consider  the  PROJECT  entity  with  the  attributes  project  identifier,  project  sponsor  identifier, 
and  project  sponsor  phone  number.  The  key  consists  of  project  identifier.  Project  sponsor 
phone  number  is  determined  by  project  sponsor  identifier.  To  conform  to  3NF,  a  separate 
entity  should  be  defined  to  correlate  project  sponsor  identifier  and  project  sponsor  phone 

number. 

d.  Fourth  Normal  Form  (4NF).  An  attributive  entity  should  not  contain 
two  or  more  independent  nonkey  attributes. 

EXAMPLE 

Consider  the  PERSON  entity  with  an  attributive  entity  called  PERSON  EXPERIENCE 
characterized  by  the  attributes  person  identifier,  person  occupation  skill  code,  and  language 
identifier  code.  A  person  can  have  multiple  occupational  skills  and  speak  multiple  languages. 
However,  the  occupational  skill  is  independent  of  the  language  skill.  If  a  person  has 
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occupational  skills  as  a  cook,  mechanic,  and  navigator,  and  speaks  both  English  and  French, 
there  is  no  basis  for  correlating  the 

languages  to  the  occupational  skills  except  through  the  person.  An  entity  instance  containing 
two  or  more  independent  multivalued  facts  about  an  entity  (i.e.,  the  parent  entity),  is  likely  to 
contain  null  values  (e.g.,  an  entry  for  Person  Occupational  Skill  Code,  but  not  for  Language 
Identifier).  To  conform  with  4NF,  the  PERSON  EXPERIENCE  entity  should  be  split  into 
two  entities:  (1)  PERSON  OCCUPATIONAL  EXPERIENCE  with  the  attributes  person 
identifier  and  person  occupational  skill  code,  and  (2)  PERSON  LANGUAGE  with  the 
attributes  person  identifier  and  language  identifier. 

e.  Fifth  Normal  Form  (5NF).  No  redundancy  due  to  symmetric  constraints 
between  nonkey  attributes.  An  entity  is  in  fifth-normal  form  if  it  cannot  be  reconstructed 
from  several  entities  with  fewer  attributes  and  fewer  rows. 

EXAMPLE 

Consider  a  CAR  PARTS  SUPPLIER  entity  characterized  by  supplier  identifier,  car 
manufacturer  identifier,  and  car  part  type  code.  Furthermore,  suppose  there  is  a  constraint  in 
effect:  if  a  supplier  sells  a  car  part  type  (e.g.,  spark  plug,  starter,  muffler)  used  in  a  car 
produced  by  a  manufacturer  the  supplier  supports  (e.g.,  Ford,  GM,  Volkswagen),  then  the 
supplier  will  sell  the  part  for  the  car  manufacturer.  A  single  entity  with  all  three  attributes 
could  be  developed,  but  there  would  be  redundant  information  (e.g.,  for  a  specific  supplier, 
the  car  part  type  "spark  plug"  would  appear  for  each  manufacturer  the  supplier  supports).  The 
information  represented  by  this  single  entity  could  be  derived  from  three  tables  with  fewer 
columns  and  fewer  rows:  (1)  a  MANUFACTURER  PARTS  entity  characterized  by 
Manufacturer  Identifier  and  Car  Part  Type  Code,  (2)  a  SUPPLIER  PARTS  entity 
characterized  by  Supplier  Identifier  and  Car  Part  Type  Code,  and  (3)  a  MANUFACTURER 
SUPPLIER  ASSOCIATION  entity  characterized  by  Manufacturer  Identifier  and  Supplier 
Identifier. 

6.  Primary  Key  Rules.  An  entity  shall  be  uniquely  identified  by  one  or  more 
attributes  grouped  into  a  primary  key. 

a.  The  primary  key  shall  never  be  null.  The  primary  key  will  always 

occur. 


b.  The  primary  key  never  repeats.  There  is  only  one  instance  per 
occurrence  (i.e.,  one  record  per  value). 

c.  The  primary  key  should  have  no  embedded  meanings. 

d.  When  there  is  no  existing  attribute  or  set  of  attributes  that  meet  the 

above  rules: 
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(1)  Create  an  identifier  that  satisfies  the  rules. 


(2)  Evaluate  the  impacts  and  tradeoffs  of  using  the  identifier  versus 
using  other  candidate  keys  identified  for  the  entity.  In  addition  to  criteria  such  as  improved 
data  exchange  and  better  support  for  cross-functional  integration,  the  following  two  criteria 
shall  be  considered: 


(a)  Managing  uniqueness  of  the  identifier  values  across  DoD. 
If  the  identifier  is  to  be  computer  generated,  controls  and  responsibilities  shall  be  established 
for  cataloging  and  possibly  distributing  the  values  so  they  are  not  rendered  unique  only  to  the 
system  that  generates  them. 

(b)  Impacts  of  setting  up  the  identifier  (e.g.,  translating  or 
converting  existing  data  to  structures  keyed  by  the  new  identifier). 

(3)  Based  on  the  evaluation,  select  between  the  created  identifier  and 
one  of  the  alternative  candidate  keys.  If  the  created  identifier  is  selected  as  the  primary  key, 
document  the  approach  for  managing  its  uniqueness  in  comment  text  for  the  attribute  and 
identify  one  or  more  alternate  keys  from  the  list  of  candidate  keys  for  the  entity. 

e.  A  temporary  identifier  key  may  be  defined  and  used  as  a  "place  holder" 
to  support  a  phased  modeling  effort  that  will  define  a  functional  key  at  a  later  date.  However, 
this  intention  shall  be  documented  in  comment  text  for  the  attribute. 

7.  If  one  or  more  alternate  keys  are  identified  for  an  entity,  these  keys  shall  never 
be  null  and  shall  provide  a  unique  value  for  identifying  each  entity  instance. 

8.  Each  proposed  entity  should  have  at  least  two  attributes. 

C.  ENTITY  NAMING  RULES 

1.  The  entity  names: 

a.  Shall  be  clear,  accurate,  and  self  explanatory. 

b.  Shall  include  only  upper  case  alphabetic  characters  (A-Z)  and  spaces. 
Entity  names  may  contain  hyphens  (-)  (i.e.,  associative  entity  names  or  to  connect  multiple 
words). 


c.  Shall  be  a  singular  noun  or  noun  phrase.  A  prime-word  modifier  is  not 
required  for  standardization. 

d.  Shall  be  named  according  to  logical  and  not  physical  considerations. 
Physical  characteristics  include  any  connotations  regarding  technology  (hardware  or  software), 
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physical  location  (data  bases,  files,  reports,  forms,  or  tables),  organization  (data  steward),  or 
function  (systems,  applications,  or  programs). 

e.  Shall  consist  of  the  minimum  number  of  words  for  labeling.  The  name 
should  not  be  used  to  redefine  the  entity  nor  contain  information  that  more  correctly  belongs 
in  the  definition. 

f.  May  contain  a  class  word,  such  as  date  or  time,  if  appropriate.  Class 
words  are  centrally  controlled  and  managed  under  DoD  8320.1-M-l  (reference  (b)). 

2.  The  entity  name  shall  not: 

a.  Include  abbreviations  or  acronyms.  (Exceptions  to  this  rule  may  be 
granted  by  the  DoD  DAd  in  the  case  of  universally  accepted  abbreviations  or  acronyms.) 

b  Include  names  of  organizations,  computer  or  information  systems, 
directives,  forms,  screens,  or  reports. 

c.  Include  titles  of  blocks,  rows,  or  columns  of  screens,  reports,  forms,  or 

listings. 

d.  Express  multiple  concepts,  either  implicitly  or  explicitly. 

e.  Include  the  possessive  form  of  any  words. 

f.  Include  articles  (a,  an,  the). 

g.  Include  conjunctions  (and,  or,  but,  etc.). 

h.  Include  verbs. 

i.  Include  prepositions  (at,  by,  for,  from,  in,  of,  to,  etc.). 

D.  ENTITY  DEFINITION  RULES 

1.  The  entity  definition  shall: 

a.  Define  WHAT  the  entity  is,  not  HOW,  WHERE,  or  WHEN  the  entity  is 
used,  or  WHO  uses  it. 

b.  Be  more  than  just  a  reiteration  of  the  name  or  a  synonym  of  the  name. 

c.  Add  meaning  to  the  name,  not  merely  rephrase  the  name. 
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d.  Have  one  and  only  one  interpretation  and  not  be  ambiguous.  Terms 
within  the  definition  with  possible  differing  interpretations  shall  be  clearly  explained  in  the 
definition. 

e.  Be  reasonable  definitions,  such  as  those  found  in  a  common  dictionary. 
2.  The  entity  definition  shall  not: 


a.  Restrict  shareability  with  the  other  DoD  functions  or  Components. 

b.  Be  circular.  Avoid  one  definition  pointing  to  a  second  definition  for 
further  explanation  and  the  second  definition  pointing  back  to  the  original  definition. 


c.  Contain  examples.  A  definition  should  stand  on  its  own.  Use  of 
examples  may  signify  that  a  definition  is  not  complete.  Examples  may  be  captured  as 
separate  comments,  but  definitions  shall  stand  alone. 

d.  Restate  or  contain  process  or  functional  descriptions  that  describe  how  it 
is  calculated,  derived,  assimilated,  or  manipulated. 


entity. 


Restate  or  be  a  mere  list  of  the  attributes  or  meta  attributes  within  the 


f.  Contain  infinitives  to  begin  an  entity  definition.  A  simple  definition  of 
the  entity  is  all  that  is  needed.  (E.g.,  Definitions  do  not  need  to  be  prefaced  by  "This  entity 
defines..."  or  "To  describe....") 

g.  Contain  technical  jargon,  acronyms,  and  abbreviations  that  may  be 
unfamiliar  to  the  reader. 


h.  Contain  passive  phrases  such  as  "that  is"  or  "which  is"  in  a  definition 
since  that  only  makes  the  definitions  too  wordy.  Use  the  active  voice  in  a  definition  to 
provide  a  clearer  and  more  concise  meaning. 


i.  Contain  conjunctions  such  as  "and"  or  "or"  since  they  may  indicate 
ambiguity,  multiple  concepts,  or  a  process  orientation.  Avoid  conjunctions;  when  a 
conjunction  appears  in  the  subject  of  a  phrase,  it  may  indicate  a  multiple  concept. 

j.  Use  "Any"  or  "Some"  to  begin  a  definition.  Using  "A"  or  "An" 
expresses  a  single  concept  where  as  using  "Any"  or  "Some"  may  signify  multiple  concepts. 
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CHAPTER  7 


DoD  ENTERPRISE  DATA  MODEL  MAINTENANCE  PROCEDURES 


A.  INTRODUCTION 

1 .  This  chapter  describes  procedures  for  storing  and  updating  the  DoD  Enterprise 
Data  Model.  The  DoD  Interim  IDEF  Repository  and  the  DDRS  will  be  the  primary  tools 
used  to  support  these  procedures.  The  DoD  Enterprise  Data  Model  will  be  stored  and 
maintained  in  the  DoD  Interim  IDEF  Repository.  The  entities  and  their  attributes  (as  prime 
words  and  standard  data  elements)  will  be  stored  and  maintained  in  the  DDRS. 

2.  Contact  the  CIM  Center  for  Functional  Process  Improvement  Expertise  to 
obtain  access  to  and  documentation  for  the  DoD  Interim  IDEF  Repository.  Contact  DAPMO 
to  obtain  access  to  and  documentation  for  the  DDRS. 

3.  Configuration  management  of  changes  to  the  DoD  Enterprise  Data  Model  is 
DoD  DAd's  responsibility.  Configuration  management  efforts  are  supported  by 
representatives  from  DAPMO,  FDAds,  and  CDAds. 

B.  STORE  DoD  ENTERPRISE  DATA  MODEL 

1 .  As  new  entities,  attributes,  or  relationships  are  approved  and  incorporated  into 
the  DoD  Enterprise  Data  Model,  new  versions  of  the  DoD  Enterprise  Data  Model  will  be 
produced.  New  versions  will  be  stored  in  the  DoD  Interim  IDEF  Repository. 

2.  The  DDRS  will  be  used  to  store  and  maintain  prime  words  (entities)  and  data 
elements  (attributes).  Version  numbers  will  be  used  to  maintain  historical  versions  of  prime 
words  and  data  elements  in  the  DDRS  over  time.  This  history  of  changes  will  be  available 
for  reference  and  audit  purposes.  These  changes  include  status  changes  from  Approved,  to 
Archived,  to  Reinstated,  etc. 

3.  Prime  words  and  data  elements  should  be  accessed  in  the  DDRS  for  review  and 
comment  during  the  review  and  approval  process. 

4.  Attributes  of  approved  entities  may  be  submitted  for  approval  as  standard  DoD 
data  elements  in  accordance  with  data  element  standardization  procedures  outlined  in  DoD 
8320.1-M-l  (reference  (b)). 

5.  New  versions  of  the  DoD  Enterprise  Data  Model  will  be  published  quarterly. 

6.  Historical  versions  of  the  DoD  Enterprise  Data  Model  will  be  archived  and 
used  for  reference  and  audit  trail. 
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c.  ITPDATF,  DoD  ENTERPRISE  DATA  MODEL 

1.  As  new  information  requirements  are  identified,  the  DoD  Enterprise  Data 
Model  will  change,  therefore  causing  entities,  attributes,  and  relationships  to  be  added, 
modified,  archived,  or  reinstated.  The  following  procedures  summarize  processes  for 
maintaining  the  DoD  Enterprise  Data  Model.  Review  procedures  to  be  followed  for  new, 
modified,  candidate  for  archive,  and  candidate  for  reinstatement  proposals  are  discussed  in 
Chapter  4.  A  description  of  the  different  prime  word  (entity)  and  data  element  (attribute) 
standardization  phases  is  provided  in  Chapter  3.  More  detailed  configuration  management 
procedures  for  the  DoD  Enterprise  Data  Model  will  be  published  in  the  DoD  Enterprise  Data 
Model  Configuration  Management  Plan. 

2.  New  Entities  and  Attributes.  New  information  requirements  are  submitted  in 
proposal  packages  based  on  functional  area  data  models  to  extend  the  DoD  Enterprise  Data 
Model.  Each  new  entity  (prime  word)  and  attribute  (data  element)  should  be  entered  into  the 
DDRS  where  a  version  number,  counter  identifier,  and  status  of  Developmental  are  assigned. 
Once  entered  into  the  DDRS,  reviewers  will  have  centralized  access  and  automated  support 
for  reviewing  and  commenting  on  the  proposed  prime  words  and  data  elements.  Version 
numbers  are  assigned  to  prime  words  and  data  elements  to  record  and  track  changes  over 
time.  Unique  counter  identifiers  are  identifiers  assigned  to  each  prime  word  and  data  element 
for  use  in  quick  and  easy  access  by  DDRS  users.  The  status  is  used  to  record  and  track 
progress  through  the  review  and  approval  process  for  a  given  version  of  a  prime  word  or  data 
element. 

3.  Modifying  Approved  Entities.  Attributes,  and  Relationships.  Modifications 
may  be  proposed  for  any  approved  entity  and  associated  attributes  and  relationships.  Entities 
and  relationships  will  be  modified  in  accordance  with  the  same  review  procedures  as  new 
entities  and  attributes.  Approved  attributes  will  be  modified  in  accordance  with  DoD 
8320.1-M-l  (reference  (b)).  Each  time  a  proposal  is  made  to  change  an  entity  or  attribute,  a 
new  version  of  the  associated  prime  word  or  data  element  will  be  created  in  the  DDRS  with  a 
status  of  developmental  to  start  the  review  process.  The  incremented  version  number  will 
indicate  that  the  proposal  associated  with  the  prime  word  or  data  element  is  a  modification. 

If  the  modified  entity  or  attribute  is  approved,  the  status  of  the  previously  approved  version 
will  be  set  to  archived,  and  all  registered  users  of  the  older  version  will  be  notified  of  the 
change. 

4.  Archiving  Approved  Entities.  Attributes,  and  Relationships 

a.  Approved  entities  along  with  associated  attributes  and  relationships  may 
be  archived  based  on  their  lack  of  recorded  use.  The  effected  subset  of  the  DoD  Enterprise 
Data  Model  representing  the  archived  entities,  attributes,  and  relationships  will  be  retained  for 
historical  reference  and  possible  reinstatement,  based  on  changing  information  and  reporting 
requirements.  Approved  attributes  shall  be  archived  as  data  elements  in  accordance  with  DoD 
8320.1-M-l  (reference  (b)). 
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b.  FDAds  will  identify  entities  along  with  associated  attributes  and 
relationships  that  are  no  longer  deemed  as  information  or  business  rule  requirements.  The 
DoD  DAd  may  notify  an  FDAd  and  recommend  that  entities  along  with  associated  attributes 
and  relationships  be  considered  for  archive  if  no  information  systems  are  registered  in  the 
DDRS  as  users  of  a  prime  word. 

c.  Archiving  may  be  proposed  for  any  approved  entity.  The  proposal 
review  procedures  that  apply  to  approving  candidate  entities  also  apply  to  approving  entities 
for  archive  along  with  associated  attributes  and  relationships.  When  an  entity  is  proposed  for 
archive,  a  new  version  of  an  entity  is  created  in  the  DDRS  to  support  the  review  process. 

d.  Based  on  the  proposed  recommendation  to  archive  an  entity  along  with 
associated  attributes  and  relationships,  the  FDAds  will  jointly  assess  functional  needs  to  retain 
the  entity  via  the  formal  review  process. 

(1)  If  the  FDAd  designated  as  the  proposal  package  functional  data 
steward  disapproves  the  proposal  to  archive,  then  the  DoD  DAd  shall  retain  the  approved 
entity,  attributes,  and  relationships  in  their  existing  status. 

(2)  If  the  FDAd  designated  as  the  data  steward  determines  that  there 
is  no  functional  need  and  approves  the  proposal  to  archive,  the  DoD  DAd  will  establish  the 
effective  date  for  archiving  the  entity,  attributes,  and  relationships  and  will  change  the  status 
of  the  latest  version  of  the  prime  word  and  associated  data  elements  from  Candidate  (for 
archive)  to  Archived. 

5.  Reinstating  Archived  Entities.  Attributes,  and  Relationships 

a.  A  review  of  the  DoD  Enterprise  Data  Model  and  the  DDRS  during  the 
data  model  development  or  modification  process  may  locate  an  archived  entity  along  with 
associated  attributes  and  relationships  that  are  suitable  for  reuse.  In  such  case,  the  archived 
entity,  attributes,  and  relationships  may  be  reinstated.  Archived  attributes  shall  be  reinstated 
in  accordance  with  DoD  8320.1-M-l  (reference  (b)). 

(1)  An  archived  entity,  along  with  associated  attributes  and 
relationships,  may  be  proposed  for  reinstatement  without  modification.  When  this  happens,  a 
new  version  of  the  entity  is  created  in  the  DDRS  with  a  status  of  candidate  (for 
reinstatement),  and  a  formal  review  is  performed. 

(2)  An  archived  entity  along  with  associated  attributes  and 
relationships  being  proposed  for  reinstatement  with  modification  shall  be  submitted  as  a  new 
developmental  entity  in  accordance  with  procedures  in  Chapter  5. 

b.  FDAds  will  jointly  review  the  candidate  for  reinstatement  for 
applicability  and  accuracy  via  the  formal  review  process.  If  the  FDAd  designated  as  the 
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proposal  package  functional  data  steward  approves  reinstatement,  the  DoD  DAd  will  change 
the  status  of  the  new  version  of  the  entity  to  Approved  and  assign  an  effective  date. 

c.  After  the  archived  entity  along  with  associated  attributes  and 
relationships  are  reinstated,  models  using  the  prime  word  (entity)  and  applications  using  the 
standard  data  elements  should  be  registered  in  the  DDRS  in  accordance  with  Section  D, 
below  and  DoD  8320.1-M-l  (reference  (b)). 

D  APPROVED  F.NTTTY  (PR IMF.  WORD)  AND  ATTRIBUTE  (DATA  ELEMENT), 
REGISTRATION 

1.  As  approved  entities  (prime  words)  and  attributes  (data  elements)  are 
implemented  in  new  functional  area  models  and  AISs,  their  use  should  be  registered  in  the 

DDRS. 


2.  Invitations  to  contribute  to  the  review  of  change  proposals  for  approved  entities 
(prime  words)  or  attributes  (data  elements)  will  be  limited  to  FDAds,  CDAds,  the  DoD  DAd, 
and  registered  users  of  the  entities  (prime  words)  and  attributes  (data  elements). 
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APPENDIX  A 


DATA  ELEMENT  STANDARDIZATION 


A.  PURPOSE 


This  appendix  describes  concepts  that  are  fundamental  to  the  development  of  standard 
data  elements.  Without  an  approved  DoD  Enterprise  Data  Model,  approved  entities,  and 
attributes,  DoD  standard  data  elements  and  their  metadata  cannot  exist. 

B.  DATA  ELEMENT  STANDARDIZATION 

Data  element  standardization  is  achieved  by  using  the  two-step  process  of  (1)  logically 
identifying  and  defining  data  and  (2)  classifying  data. 

1 .  The  DoD  Enterprise  Data  Model  is  a  logical  representation  of  DoD  data  and 
how  it  is  categorized  based  upon  information  requirements.  Data  elements  are  derived  from 
this  logical  grouping  of  data.  The  purpose  of  this  logical  grouping  is  to  define,  name,  and 
identify  characteristics  of  standard  data  elements  to  eliminate  data  redundancy  and  facilitate 
the  common  use  and  understanding  of  data. 

2.  Once  standard  data  elements  are  identified,  the  second  step  of  data 
standardization  is  to  classify  the  data  according  to  like  characteristics.  The  purpose  of  this 
classification  is  to  identify  standard  rules  for  creating,  sharing,  maintaining,  manipulating  and 
representing  like  data.  Class  words  and  generic  elements  facilitate  this  classification. 

C.  DATA  ELEMENTS 

1 .  A  data  element  is  a  basic  unit  of  information  having  a  meaning  and 
subcategories  (data  items)  of  distinct  units  and  value.  Through  its  name  and  definition,  a  data 
element  shall  convey  a  single,  informational  concept. 

2.  Data  elements  are  derived  from  attributes  associated  with  entities  identified  in 
logical  data  models.  Each  data  element  represents  an  entity/attribute  combination. 

3.  All  data  elements  shall  be  approved  and  documented  in  accordance  with  the 
DoD  standardization  procedures  and  naming  conventions  as  stated  in  DoD  8320.1-M-l 
(reference  (b)). 

4.  Prime  words  are  the  approved  entity  names.  The  data  element  name  is  created 
by  combining  the  prime  word  with  an  attribute  name,  including  class  word,  from  the  data 
model. 
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5.  The  class  word  is  selected  from  a  set  of  approved  DoD  standard  class  words. 
Class  words  are  used  to  classify  data  elements  based  upon  domains,  representation,  storage,  or 
usage.  The  class  word  is  a  requirement  of  the  data  element  naming  convention  for  data 
element  standardization. 

6.  During  data  element  standardization,  data  elements  are  further  categorized 
within  a  class  to  form  generic  elements. 

D.  PRTMF.  WORDS 

Prime  words  are  centrally  controlled  and  maintained  by  the  DoD  DAd.  Prime  words, 
as  described  in  DoD  8320.1-M-l  (reference  (b)),  are  the  approved  entities  in  the  DoD 
Enterprise  Data  Model.  Prime  words  are  reviewed  and  approved  in  accordance  with 
procedures  outlined  in  Chapter  3. 

E.  CT  ASS  WORDS  AND  GENERIC  ELEMENTS 

1.  Class  words  and  generic  elements  are  used  to  classify  and  subcategorize  data 
elements  based  on  like  definitions,  domain,  data  type,  and  format.  Class  words  classify  the 
data  at  their  highest  level.  Approved  DoD  standard  class  words  are  described  in  DoD 
8320.1-M-l  (reference  (b)).  They  are  centrally  controlled  and  maintained  by  the  DoD  DAd. 

2.  All  data  elements  are  required  to  fit  into  a  class.  If  a  new  data  element  cannot 
fit  into  a  class,  then  a  proposal  may  be  made  to  create  a  new  class  word.  Proposals  for  new 
class  words  are  submitted  via  an  FDAd  or  CDAd  to  the  DoD  DAd.  The  DASD(IM)  approves 
new  class  words  based  upon  FDAd  and  DoD  DAd  recommendations. 

3.  The  approval  of  new  class  words  shall  be  based  on: 

a.  The  analysis  of  existing  data  elements  to  ensure  that  an  existing  class 
cannot  be  modified  to  include  the  new  category, 

b.  Extension  of  the  DoD  Enterprise  Data  Model  to  ensure  that  data 
elements  will  be  created  to  fit  into  this  new  class,  and 

c.  Information  management  requirements  to  manage  a  new  class  of  data 
for  which  standard  rules  are  required. 

4.  To  develop  generic  elements: 

a.  First,  classify  the  data  element  into  a  standard  class. 

b.  Second,  subcategorize  the  data  elements  within  the  class  based  on  like 
definitions,  domain,  data  type,  and  format. 
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5.  Generic  elements  are  developed  and  approved  via  the  procedures  documented 
in  DoD  8320.1-M-l  (reference  (b)). 
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APPENDIX  B 


DATA  MODELING  AND  BUSINESS  PROCESS  REENGINEERING 


A.  PURPOSE 

1.  This  appendix  provides  an  overview  of  how  data  modeling  supports  BPR  and 
the  Information  System  Life-Cycle  Management  Program  described  in  DoD  8120.1.  Through 
the  Defense  Information  Management  program,  the  Department  will  emphasize  the  primacy  of 
functional  requirements  and  the  supporting  role  of  information  technology. 

2.  The  success  of  BPR  lies  in  the  ability  of  functional  managers  to  completely 
understand  the  process  or  activity  being  analyzed.  This  requires  information  and  insight  not 
only  about  what  is  being  done,  but  also  about  the  data  needed  to  execute  the  process,  data 
that  result  from  the  process,  and  business  rules  that  act  as  constraints  on  the  way  the  data  are 
processed. 

3.  Business  processes  are  easier  to  understand  when  they  are  viewed  from 
multiple  perspectives.  Data  models  are  used  to  logically  and  accurately  depict  the  data  and 
information  required  to  support  both  individual  functional  processes  and  cross-functional 
requirements.  Data  models  help  functional  managers  communicate  information  requirements 
for  both  "AS  IS"  and  "TO  BE"  activity  models  representing  a  process  being  analyzed  for 
improvement  opportunities. 

4.  Major  economic  benefits  can  normally  be  expected  from  information  system 
development  projects  when  the  systems  are  designed  to  support  functional  processes  and  data 
management  practices  that  have  been  engineered  to  take  advantage  of  the  new  technologies 
available.  The  new  technologies  available  may  make  BPR  possible,  but  inserting  new 
technologies  into  an  organization  without  engineering  the  processes  and  supporting  data 
management  activities  normally  produces  little  or  no  benefit. 

B.  OVERVIEW  OF  DOD  8000  SERIES  OPERATIONS 


Figure  C-l  depicts  interdependencies  among  the  three  DoD  initiatives  that  share 
objectives  for  improving  cost  effectiveness  for  DoD  operations  and  management: 

1.  Business  Process  Reengineering  ('BPR') 

Functional  area  program  managers  identify  processes  to  be  evaluated  and 
analyzed  for  improvement  opportunities.  BPR  initiatives  involve  FDAds  in  developing 
data  models  to  coordinate  and  communicate  data  requirements  that  support  improved 
processes. 
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DoD  Mission  Charter  Statements 


Figure  B-l  -  DoD  8000  Series  Process  Overview 


a.  Teams  of  component  and  functional  area  SMEs  assemble  to  determine 
the  functional  management  strategy  to  be  followed  in  streamlining  and  standardizing 
processes,  and  establishing  the  process,  data,  and  information  system  baselines  (i.e.,  develop 
"AS  IS"  models)  from  which  to  begin  process  improvement. 

b.  The  teams  evaluate  the  functional  processes  for  improvement 
opportunities  to  eliminate  nonvalue-added  processes,  simplify  and  streamline  limited  value- 
added  processes,  and  identify  more  effective  and  efficient  alternatives  to  the  process,  data,  and 
system  baselines  (i.e.,  develop  alternative  "TO  BE"  models).  Improvement  opportunities 
include  operational  considerations  for  consolidating  component  systems  supporting  like 
functions  in  different  organizations.  If  multiple  alternatives  to  the  baseline  are  documented,  a 
preferred  alternative  is  selected  based  upon  a  preliminary  functional  economic  analysis. 

c.  FDAds,  CD  Ads,  and  SMEs  assist  in  developing  the  "AS  IS"  data  model, 
identifying  changes  to  data  requirements  to  accommodate  process  improvements  and 
developing  the  "TO  BE"  data  models.  Submission,  review,  and  approval  of  these  models  is 
performed  through  the  8320.1  process,  which  produces  an  integrated  DoD  functional  area 
model  called  the  DoD  Enterprise  Data  Model,  and  standardized  data  elements. 

d.  The  process  improvement  recommendations  are  reviewed  and  approved 
by  the  OSD  PSA,  providing  authorization  for  updating  the  Functional  Area  Integrated 
Functional  Architecture.  Approved  data  models  become  supporting  documents  for  process 
improvement  implementation  plans,  evaluation  decision  packages,  and  approval  decision 
packages.  These  plans  and  decision  packages  identify  actions  that  will  be  taken  to  implement 
recommended  changes  to  processes,  data,  and  supporting  information  systems  based  on  results 
of  a  process  improvement  project. 

e.  Approved  process  and  data  changes  are  implemented,  and  the  revised 
processes,  data,  and  systems  become  the  new  baseline  for  future  process  improvement 
initiatives.  The  changes  include  projects  that  can  be  completed  with  and  without  adjusting 
supportive  automated  information  systems. 

2.  DoD  Data  Administration  18320.1) 

a.  Annually,  the  DAPMO  assembles  a  data  administration  strategic  plan 
from  inputs  provided  by  the  FDAds  and  CD  Ads.  The  functional  area’s  data  administration 
strategic  plan  (DASP),  prepared  by  the  FDAd,  consolidates  and  integrates  all  planned  and 
approved  changes  to  data,  whether  they  result  from  process  improvement  projects,  or  from 
other  data  administration  activities.  The  DoD  Data  Administration  Strategic  Plan  provides 
guidance  for  data  administration  activities  and  specifies  resource  requirements  for  DoD 
functional  area  and  Component  data  administration  activities. 

b.  FDAds  merge  key-based  data  models  across  BPR  projects  and  fully 
attribute  and  normalize  the  models  to  support  data  integration  and  data  standardization.  These 
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normalized  functional  models  are  then  coordinated  and  reviewed  to  support  developing  and 
extending  the  DoD  Enterprise  Data  Model,  a  DoD-wide  integrated  functional  area  data  model. 

c.  The  DoD  Enterprise  Data  Model  integration  process  categorizes  data 
elements  for  standardization  and  provides  an  analysis  tool  for  assessing  data  quality  and  data 
security-integrity  requirements  across  all  functional  areas.  Data  models  are  coordinated  for 
review  and  approval  across  functional  areas  using  procedures  described  in  this  manual.  Data 
elements  are  standardized  and  coordinated  for  review  and  approval  using  procedures 
prescribed  in  DoD  8320.1-M-l  (reference  (b)). 

d.  Data  models  and  standard  data  elements  are  maintained  in  repositories 
and  managed  as  reusable  assets  to  provide  the  basis  for  database  development.  Data  models 
are  managed  for  reuse  in  the  DoD  Interim  IDEF  Repository.  Standard  data  elements  are 
managed  for  reuse  in  the  DDRS. 

3.  DoD  8120.1  Information  System  Life-Cycle  Management 

a.  AISs  are  developed  to  consolidate  component  systems  (migration 
systems)  and  to  support  improved  processes.  Databases  for  the  AISs  are  designed  based  on 
the  data  models  and  standard  data  elements  coordinated  for  reuse  through  the  DoD  IDEF 
Repository  and  the  DDRS. 

b.  Data  models  and  data  elements  reverse  engineered  from  existing  legacy 
systems  may  provide  a  basis  for  developing  functional  area  data  models  and  standard  data 
elements.  When  reverse  engineering  is  used,  however,  these  models  shall  be  reviewed  for 
approval  using  procedures  specified  in  this  document.  Reverse-  engineered  data  elements 
proposed  for  standardization  shall  be  reviewed  and  approved  using  procedures  described  in 
DoD  8320.1-M-l  (reference  (b)). 

C.  RELATIONSHIP  OF  DATA  MODELING  TO  BUSINESS  PROCESS 
RFF.NGTNEERING 

1.  Data  models  support  both  BPR  and  DoD  Data  Administration  efforts.  FDAds 
designated  by  the  OSD  PSAs  integrate  data  models  into  a  data  architecture  that  supports  and 
is  consistent  with  Functional  Area  Integrated  Functional  Architectures.  This  includes 
key-based  data  models  developed  to  support  process  improvement  projects,  and  the  fully 
attributed  and  normalized  models  developed  from  them  to  support  data  administration  tasks 
(e.g.,  data  standardization). 

2.  FAPMs  and  the  FDAd  share  the  responsibility  for  reconciling  the  activity 
models  in  the  functional  architecture,  and  the  data  models  in  the  data  architecture  for  the 
functional  area. 

3.  Data  models  developed  to  support  BPR  analysis  are  approved  by  the  OSD 
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PSA,  together  with  the  activity  models  that  they  complement.  Extending  a  key-based  data 
model  to  a  fully  attributed  and  normalized  data  model  to  support  DoD  8320.1  requirements 
does  not  require  a  second  OSD  PSA  approval.  However,  if  data  modeling  to  support  DoD 
8320.1  data  administration  results  in  revision  of  the  previously  approved  key-based  model,  or 
the  creation  of  a  new  data  model,  then  OSD  PSA  approval  is  required. 

4.  Differences  between  the  "AS  IS"  and  "TO  BE"  data  models  reflect  changes  in 
information  requirements  that  shall  be  implemented  in  concert  with  the  process  changes 
defined  by  the  "AS  IS"  and  "TO  BE"  activity  models.  The  estimated  costs  and  benefits  of 
these  changes  are  included  in  the  functional  economic  analysis  that  is  prepared  to  evaluate  the 
process  changes.  A  data  management  plan  (DMP)  is  developed  to  plan  implementation  of  the 
data  changes  required  for  the  process  improvement  alternatives.  The  DMP  is  a  source 
document  for  finalizing  the  functional  economic  analysis. 

5.  The  FDAd  validates  all  data  models  for  conformance  to  the  Functional  Area 
Functional  Integrated  Architecture  and  the  supporting  data  architecture  before  its  incorporation 
in  a  formal  process  change  proposal.  The  FDAd  is  responsible  for  integrating  data  models 
and  standard  data  definitions  across  functional  activities  within  a  functional  area.  The  FDAd 
is  also  responsible  for  working  with  FDAds  in  other  functional  areas,  and  with  CDAds  and 
the  DoD  DAd,  to  coordinate  and  integrate  data  models  and  standard  data  definitions  across 
functional  areas,  and  to  incorporate  approved  data  models  into  the  DoD  Enterprise  Data 
Model. 


6.  The  DAPMO  reviews  data  models  for  consistency  with  the  DoD  Enterprise 
Model  and  coordinates  any  necessary  reconciliation. 

7.  The  DoD  DAd  annually  prepares  and  maintains  DoD  DASP  from  inputs 
developed  by  each  FDAd  and  CDAd.  The  DASP  provides  comprehensive,  long-term 
direction  to  improve  the  planning  and  management  of  DoD  data  resources  and  to  plan  and 
operate  data  administration  activities  within  DoD.  Migration  system  data  management  plans 
for  each  migration  system  and  active  data  management  plans  for  each  process  improvement 
project  are  sources  for  this  input. 

8.  The  DASP  and  the  functional  area  data  administration  action  plan  are  source 
documents  for  supporting  execution  of  the  functional  area  strategic  plan. 

D.  RELATIONSHIP  OF  DATA  MODELING  TO  INFORMATION  SYSTEM  LIFE- 
CYCLE  MANAGEMENT 

1.  The  functional  management  strategy  to  be  followed  in  streamlining  and 
standardization  processes  requires  that  legacy  systems  be  identified  to  support  approved 
process  and  data  baselines.  The  selected  information  systems(s)  then  evolve  in  accordance 
with  the  DoD  Directive  8120.1  Life-Cycle  Management  (LCM)  of  Automated  Information 
Systems  (AISs)  (reference  (f))  through  numerous  evolutionary  and  incremental  changes  to 
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provide  improved  functional  and  technical  capability.  These  changes  address  improvements 
in  functionality,  incorporation  of  standard  data  definitions  and  structures  to  promote 
integration  and  data  sharing,  and  technical  migration  toward  an  open  system  environment  (as 
defined  by  the  DoD  technical  architecture). 

2.  Selection  of  a  baseline  system  for  incremental  migration  to  an  open  system 
architecture  is  a  functional  decision  that  shall  be  supported  by  an  economic  analysis  of  the 
costs  and  benefits  in  comparison  to  other  competitive  alternatives. 

3.  Following  preliminary  evaluation  of  candidate  systems,  detailed  implementation 
plans  are  prepared  for  the  systems(s)  that  show  significant  potential  for  supporting  the 
baseline  requirements.  The  FDAd  assists  in  preparing  a  migration  system  DMP  with  input 
from  the  CD  Ad  and  the  DoD  DAd  as  necessary.  The  migration  system  DMP  addresses  all 
data  administration  actions  related  to  implementing  of  the  migration  system,  including  issues 
related  to  transitioning  to  standard  data  definitions  and  structures.  The  DMP  also  provides 
technical  guidance,  schedules,  and  exit/completion  criteria  to  be  met  by  the  implementors. 

4.  The  logical  data  models  created  to  support  data  administration  shall  be 
converted  to  physical  data  models  for  definition  of  actual  database  structures. 
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APPENDIX  C 


PROPOSAL  PACKAGE  CHECKLIST 


This  appendix  provides  a  set  of  checklists  for  use  in  preparing  a  functional 
area/component-level  model  for  submission  to  the  8320.1-M-x  DoD  Enterprise  Data  Model 
review,  approval,  and  maintenance  process.  The  following  checklists  are  provided: 

A.  Basic  Proposal  Package  Information  Checklist 

B.  Entity  Information  Checklist 

C.  Attribute  Information  Checklist 

D.  Relationship  Information  Checklist 

E.  Compliance  Checklist 
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A.  BASIC  PROPOSAL  PACKAGE  CHECKLIST 


Proposed  Model  ERD  _ 


Proposed  Model 


Overall  Model  (if  package  contains  a  model 
subset)  _ 


Relative  Components  of  the  DoD  Enterprise 
Data  Model  Included.  _ 


Basic  Package  Information  _ 


Sponsoring  Organization 


Model  Originator/POC  Name 


Model  Originator/POC  Address 


Model  Originator/POC  Phone  # 


DoD  Enterprise  Data  Model 

Version  Number  _ 


Submitting  FDAd/CDAd  Name 


Submitting  FDAd/CDAd  Org.  _ 


Proposal  Package  Data  Steward 


Functional  Area  ID 


Model  Entities  Count 


Model  Attributes  Count 


Model  Relationships  Count  _ 


Tool  Used  to  Generate  ERD(s) 


List  of  Information  Systems 
Supported  by  the  ERD 


Schema  Type 

(if  IDEF1X  not  used) 


Modeling  Technique 

(if  IDEF1X  not  used)  _ 


ERD  Notation  Summary 
(if  IDEF1X  not  used) 


In  the  Req'd  (required)  column,  possible  values  are  "Y"  for  required,  "N"  for  not 
required,  and  "C"  for  conditionally  required  (required  if  applicable). 
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Req'd 

Hardcopy 

Softcopy 

DDRS 

Entity 

Name 

Y 

Definition  * 

Y 

Data  Steward  * 

N 

Functional  Area  ID 

Y 

DDRS  Counter  ID 

N 

Attributes 

Names 

Y 

Key  Designations 

Y 

Entity  Submission  Type  * 

Y 

Prime  Word  Using  Model 

Name(s) 

Y 

*  Not  required  in  hardcopy  or  softcopy  if  entered  into  the  DDRS. 

In  Req'd  (required)  column,  possible  values  are  "Y"  for  required  and  "N"  for 

not  required. 
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c.  ATTRIBUTE  INFORMATION  CHECKLIST  (FOR  EACH  ATTRIBUTE 


Req'd 

Hardcopy 

Softcopy 

DDRS 

Attribute  _ 


Name 


Definition  *  _ 


DDRS  Counter  Identifier 


Attribute  Role  _ 


Metadata  Information  *  _ 


Data  Value  Source  List 


Decimal  Place  Count  Quantity 


Authority  Reference  Text 


Domain  Definition  Text 


Domain  Value  Identifiers 


Domain  Value  Identifier  Text 


High-range  Identifier 


Low-range  Identifier 


Maximum  Character  Count 


Security  Class.  Code 


Proposed  Steward  Name 


Functional  Area  Id 


Unit  Measure  Name 


Data  Type  Name  _ 


Derivation  Type  Name 


Formula  Definition  Text 


*  Not  required  in  hardcopy  or  softcopy  if  entered  into  the  DDRS. 

In  Req'd  (required)  column,  possible  values  are  "Y"  for  required,  "N"  for  not  required, 
and  "C"  for  conditionally  required  (required  if  applicable). 
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D.  RELATIONSHIP  INFORMATION  CHECKLIST  (FOR  EACH  RELATIONSHIP 


Relationships  between  proposed  entities 


Business  Rule 


Cardinality  -  Degree 


Cardinality  -  Nature 


Relationships  to  the  DoD  Enterprise 
Data  Model 


Business  Rule 


Cardinality  -  Degree 


Cardinality  -  Nature 


In  Req'd  (required)  column,  "Y"  indicates  required. 
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E.  COMPLIANCE  CHECKLIST 


Technical  Compliance  Checked 

8320.1-M-x  Chapter  5 

8320.1- M-x  Chapter  7 

FIPS  PUB  184 _ 

8320.1- M-l _ 

Functional  Compliance  Checked 
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